summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/intel
AgeCommit message (Collapse)AuthorFilesLines
2013-02-17igb: Remove artificial restriction on RQDPC stat readingAlexander Duyck1-3/+5
commit ae1c07a6b7ced6c0c94c99e3b53f4e7856fa8bff upstream. For some reason the reading of the RQDPC register was being artificially limited to 4K. Instead of limiting the value we should read the value and add the full amount. Otherwise this can lead to a misleading number of dropped packets when the actual value is in fact much higher. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Vinson Lee <vlee@twitter.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-21igb: release already assigned MSI-X interrupts if setup failsStefan Assmann1-6/+16
commit 52285b762b3681669215bf1d17ca6143448ab7d3 upstream. During MSI-X setup the system might run out of vectors. If this happens the already assigned vectors for this NIC should be freed before trying the disable MSI-X. Failing to do so results in the following oops. kernel BUG at drivers/pci/msi.c:341! [...] Call Trace: [<ffffffff8128f39d>] pci_disable_msix+0x3d/0x60 [<ffffffffa037d1ce>] igb_reset_interrupt_capability+0x27/0x5c [igb] [<ffffffffa037d229>] igb_clear_interrupt_scheme+0x26/0x2d [igb] [<ffffffffa0384268>] igb_request_irq+0x73/0x297 [igb] [<ffffffffa0384554>] __igb_open+0xc8/0x223 [igb] [<ffffffffa0384815>] igb_open+0x13/0x15 [igb] [<ffffffff8144592f>] __dev_open+0xbf/0x120 [<ffffffff81443e51>] __dev_change_flags+0xa1/0x180 [<ffffffff81445828>] dev_change_flags+0x28/0x70 [<ffffffff814af537>] devinet_ioctl+0x5b7/0x620 [<ffffffff814b01c8>] inet_ioctl+0x88/0xa0 [<ffffffff8142e8a0>] sock_do_ioctl+0x30/0x70 [<ffffffff8142ecf2>] sock_ioctl+0x72/0x270 [<ffffffff8118062c>] do_vfs_ioctl+0x8c/0x340 [<ffffffff81180981>] sys_ioctl+0xa1/0xb0 [<ffffffff815161a9>] system_call_fastpath+0x16/0x1b Code: 48 89 df e8 1f 40 ed ff 4d 39 e6 49 8b 45 10 75 b6 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f c9 c3 48 8b 7b 20 e8 3e 91 db ff eb ae <0f> 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00 RIP [<ffffffff8128e144>] free_msi_irqs+0x124/0x130 RSP <ffff880037503bd8> Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com>
2012-12-03ixgbe: add support for X540-AT1joshua.a.hay@intel.com4-0/+5
commit df376f0de167754da9b3ece4afdb5bb8bf3fbf3e upstream. This patch adds device support for Ethernet Controller X540-AT1. Signed-off-by: Josh Hay <joshua.a.hay@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Abdallah Chatila <Abdallah.Chatila@ericsson.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-21e1000e: Change wthresh to 1 to avoid possible Tx stallsHiroaki SHIMODA2-4/+4
commit 8edc0e624db3756783233e464879eb2e3b904c13 upstream. This patch originated from Hiroaki SHIMODA but has been modified by Intel with some minor cleanups and additional commit log text. Denys Fedoryshchenko and others reported Tx stalls on e1000e with BQL enabled. Issue was root caused to hardware delays. They were introduced because some of the e1000e hardware with transmit writeback bursting enabled, waits until the driver does an explict flush OR there are WTHRESH descriptors to write back. Sometimes the delays in question were on the order of seconds, causing visible lag for ssh sessions and unacceptable tx completion latency, especially for BQL enabled kernels. To avoid possible Tx stalls, change WTHRESH back to 1. The current plan is to investigate a method for re-enabling WTHRESH while not harming BQL, but those patches will be later for net-next if they work. please enqueue for stable since v3.3 as this bug was introduced in commit 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c Author: Tom Herbert <therbert@google.com> Date: Mon Nov 28 16:33:16 2011 +0000 e1000e: Support for byte queue limits Changes to e1000e to use byte queue limits. Reported-by: Denys Fedoryshchenko <denys@visp.net.lb> Tested-by: Denys Fedoryshchenko <denys@visp.net.lb> Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com> CC: eric.dumazet@gmail.com CC: therbert@google.com Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-08-15e1000e: NIC goes up and immediately goes downTushar Dave1-3/+1
commit b7ec70be01a87f2c85df3ae11046e74f9b67e323 upstream. Found that commit d478eb44 was a bad commit. If the link partner is transmitting codeword (even if NULL codeword), then the RXCW.C bit will be set so check for RXCW.CW is unnecessary. Ref: RH BZ 840642 Reported-by: Fabio Futigami <ffutigam@redhat.com> Signed-off-by: Tushar Dave <tushar.n.dave@intel.com> CC: Marcelo Ricardo Leitner <mleitner@redhat.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-19e1000e: Correct link check logic for 82571 serdesTushar Dave1-0/+3
commit d0efa8f23a644f7cb7d1f8e78dd9a223efa412a3 upstream. SYNCH bit and IV bit of RXCW register are sticky. Before examining these bits, RXCW should be read twice to filter out one-time false events and have correct values for these bits. Incorrect values of these bits in link check logic can cause weird link stability issues if auto-negotiation fails. Reported-by: Dean Nelson <dnelson@redhat.com> Signed-off-by: Tushar Dave <tushar.n.dave@intel.com> Reviewed-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-16e1000e: test for valid check_reset_block function pointerBruce Allan4-8/+12
commit 470a54207ccf7045a59df727573bd9d148988582 upstream. commit 44abd5c12767a8c567dc4e45fd9aec3b13ca85e0 introduced NULL pointer dereferences when attempting to access the check_reset_block function pointer on 8257x and 80003es2lan non-copper devices. This fix should be applied back through 3.4. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-16e1000e: remove use of IP payload checksumBruce Allan2-61/+15
commit 2e1706f234f86ff71056ef69683d734fbf7e9e40 upstream. Currently only used when packet split mode is enabled with jumbo frames, IP payload checksum (for fragmented UDP packets) is mutually exclusive with receive hashing offload since the hardware uses the same space in the receive descriptor for the hardware-provided packet checksum and the RSS hash, respectively. Users currently must disable jumbos when receive hashing offload is enabled, or vice versa, because of this incompatibility. Since testing has shown that IP payload checksum does not provide any real benefit, just remove it so that there is no longer a choice between jumbos or receive hashing offload but not both as done in other Intel GbE drivers (e.g. e1000, igb). Also, add a missing check for IP checksum error reported by the hardware; let the stack verify the checksum when this happens. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-16igbvf: fix divide by zeroMitch A Williams1-11/+18
commit 0e90b49ca4b891f085b57559a3071a4feefb496c upstream. Using ethtool -C ethX rx-usecs 0 crashes with a divide by zero. Refactor this function to fix this issue and make it more clear what the intent of each conditional is. Add comment regarding using a setting of zero. CC: David Ahern <daahern@cisco.com> Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-16ixgbe: Do not pad FCoE frames as this can cause issues with FCoE DDPAlexander Duyck3-7/+13
commit 57efd44c8cad440fb00ef8078cb018ab2f221373 upstream. FCoE target mode was experiencing issues due to the fact that we were sending up data frames that were padded to 60 bytes after the DDP logic had already stripped the frame down to 52 or 56 depending on the use of VLANs. This was resulting in the FCoE DDP logic having issues since it thought the frame still had data in it due to the padding. To resolve this, adding code so that we do not pad FCoE frames prior to handling them to the stack. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-22e1000e: Remove special case for 82573/82574 ASPM L1 disablementChris Boot1-8/+0
commit 59aed95263bdd0e2b48eb9be5a94346d2d4abf90 upstream. For the 82573, ASPM L1 gets disabled wholesale so this special-case code is not required. For the 82574 the previous patch does the same as for the 82573, disabling L1 on the adapter. Thus, this code is no longer required and can be removed. Signed-off-by: Chris Boot <bootc@bootc.net> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-22e1000e: Disable ASPM L1 on 82574Chris Boot1-1/+2
commit d4a4206ebbaf48b55803a7eb34e330530d83a889 upstream. ASPM on the 82574 causes trouble. Currently the driver disables L0s for this NIC but only disables L1 if the MTU is >1500. This patch simply causes L1 to be disabled regardless of the MTU setting. Signed-off-by: Chris Boot <bootc@bootc.net> Cc: "Wyborny, Carolyn" <carolyn.wyborny@intel.com> Cc: Nix <nix@esperi.org.uk> Link: https://lkml.org/lkml/2012/3/19/362 Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-18e1000: Prevent reset task killing itself.Tushar Dave1-1/+5
Killing reset task while adapter is resetting causes deadlock. Only kill reset task if adapter is not resetting. Ref bug #43132 on bugzilla.kernel.org CC: stable@vger.kernel.org Signed-off-by: Tushar Dave <tushar.n.dave@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-11igb: fix rtnl race in PM resume pathBenjamin Poirier1-14/+6
Since the caller (PM resume code) is not the one holding rtnl, when taking the 'else' branch rtnl may be released at any moment, thereby defeating the whole purpose of this code block. Signed-off-by: Benjamin Poirier <bpoirier@suse.de> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-04e1000: Silence sparse warnings by correcting typeAndrei Emeltchenko1-2/+2
Silence sparse warnings shown below: ... drivers/net/ethernet/intel/e1000/e1000_main.c:3435:17: warning: cast to restricted __le64 drivers/net/ethernet/intel/e1000/e1000_main.c:3435:17: warning: cast to restricted __le64 ... Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-05-04igb, ixgbe: netdev_tx_reset_queue incorrectly called from tx init pathJohn Fastabend3-4/+6
igb and ixgbe incorrectly call netdev_tx_reset_queue() from i{gb|xgbe}_clean_tx_ring() this sort of works in most cases except when the number of real tx queues changes. When the number of real tx queues changes netdev_tx_reset_queue() only gets called on the new number of queues so when we reduce the number of queues we risk triggering the watchdog timer and repeated device resets. So this is not only a cosmetic issue but causes real bugs. For example enabling/disabling DCB or FCoE in ixgbe will trigger this. CC: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: John Bishop <johnx.bishop@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-05-03ixgbe: dcb: BIT_APP_UPCHG not set by ixgbe_copy_dcb_cfg()John Fastabend3-28/+22
After this commit: commit aacc1bea190d731755a65cb8ec31dd756f4e263e Author: Multanen, Eric W <eric.w.multanen@intel.com> Date: Wed Mar 28 07:49:09 2012 +0000 ixgbe: driver fix for link flap The BIT_APP_UPCHG bit is no longer set when ixgbe_dcbnl_set_all() is called. This results in the FCoE app user priority never getting set and the driver will not configure the tx_rings correctly for FCoE packets which use the SAN MTU and FCoE offloads. We resolve this regression by fixing ixgbe_copy_dcb_cfg() to also check for FCoE application changes. Additionally, we can drop the IEEE variants of get_dcb_app() because this path is never called with the IEEE mode enabled. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-05-03ixgbe: fix race condition with shutdownDon Skidmore1-0/+2
It was possible for shutdown to pull the rug out from other driver entry points. Now we just grab the rtnl lock before taking everything apart. Thanks to Hariharan for noticing this tight race condition. Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Cc: Hariharan Nagarajan <hanagara@cisco.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-05-01ixgbe: fix calling skb_put on nonlinear skb assertion bugYi Zou1-0/+1
With the support to bounce buffer added, the skb is coming as nonlinear in the case of non-DDPed data frames for FCoE, which is mostly ok as the FCoE stack would take care of that. However, for target mode, we have to set the FC CRC and FC EOF field to allow the protocol stack to not drop the frame for the last data frame of that sequence. So fix this by linearizing the skb first before doing skb_put(). Signed-off-by: Yi Zou <yi.zou@intel.com> Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-05-01ixgbe: Fix a memory leak in IEEE DCBAlexander Duyck1-4/+5
The driver was freeing memory in shutdown instead of remove. As a result we were leaking memory if IEEE DCB was enabled and we loaded/unloaded the driver. This change moves the freeing of the memory into the remove routine where it belongs. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Acked-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-05-01igbvf: fix the bug when initializing the igbvfSamuel Liao1-2/+2
Maybe it's a typo, but it cause that igbvf can't be initialized successfully. Set perm_addr value using valid dev_addr, although which is equal to hw.mac.addr. Signed-off-by: Samuel Liao <samuelliao@tencent.com> Signed-off-by: Shan Wei <davidshan@tencent.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-04-25e1000e: Fix default interrupt throttle rate not set in NIC HWJeff Kirsher1-46/+53
Based on the original patch from Ying Cai <ycai@google.com> This change ensures that the itr/itr_setting adjustment logic is used, even for the default/compiled-in value. Context: When we changed the default InterruptThrottleRate value from default (3 = dynamic mode) to 8000 for example, only adapter->itr_setting (which controls interrupt coalescing mode) was set to 8000, but adapter->itr (which controls the value set in NIC register) was not updated accordingly. So from ethtool, it seemed the interrupt throttling is enabled at 8000 intr/s, but the NIC actually was running in dynamic mode which has lower CPU efficiency especially when throughput is not high. CC: Ying Cai <ycai@google.com> CC: David Decotigny <david.decotigny@google.com> Signed-off-by: Jeff Kirsher <jeffrey.kirsher@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
2012-04-25e1000e: MSI interrupt test failed, using legacy interruptPrasanna S Panchamukhi1-1/+1
Following logs where seen on Systems with multiple NICs, while using MSI interrupts as shown below: Feb 16 15:09:32 (none) user.notice kernel: 0000:00:0d.0: lan0_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:32 (none) user.notice kernel: 0000:40:0d.0: wan0_1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:32 (none) user.notice kernel: 0000:40:0d.0: lan0_1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:32 (none) user.warn kernel: 0000:40:0e.0: wan4_0: MSI interrupt test failed, using legacy interrupt. Feb 16 15:09:32 (none) user.notice kernel: 0000:00:0e.0: wan1_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0e.0: lan1_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0f.0: wan2_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0f.0: lan2_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:33 (none) user.notice kernel: 0000:40:0a.0: wan3_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:33 (none) user.notice kernel: 0000:40:0a.0: lan3_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0e.0: lan4_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0f.0: wan5_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0f.0: lan5_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX This patch fixes this problem by increasing the msleep from 50 to 100. Signed-off-by: Prasanna S Panchamukhi <ppanchamukhi@riverbed.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-04-18ixgbe: Identify FCoE rings earlier to resolve memory corruption w/ FCoEAlexander Duyck2-8/+10
This patch makes it so that we identify FCoE rings earlier than ixgbe_set_rx_buffer_len. Instead we identify the Rx FCoE rings at allocation time in ixgbe_alloc_q_vector. The motivation behind this change is to avoid memory corruption when FCoE is enabled. Without this change we were initializing the rings at 0, and 2K on systems with 4K pages, then when we bumped the buffer size to 4K with order 1 pages we were accessing offsets 2K and 6K instead of 0 and 4K. This was resulting in memory corruptions. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Acked-by: Yi Zou <yi.zou@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-04-18ixgbe: add missing rtnl_lock in PM resume pathBenjamin Poirier1-0/+2
Upon resume from standby, ixgbe may trigger the ASSERT_RTNL() in netif_set_real_num_tx_queues(). The call stack is: netif_set_real_num_tx_queues ixgbe_set_num_queues ixgbe_init_interrupt_scheme ixgbe_resume Signed-off-by: Benjamin Poirier <bpoirier@suse.de> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-04-14ixgbe: fix WoL issue with fiberDon Skidmore1-0/+10
There are times we turn of the laser before shutdown. This is a bad thing if we want to wake on lan to work so now we make sure the laser is on before shutdown if we support WoL. Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-04-14e1000e: issues in Sx on 82577/8/9Bruce Allan1-5/+10
A workaround was previously put in the driver to reset the device when transitioning to Sx in order to activate the changed settings of the PHY OEM bits (Low Power Link Up, or LPLU, and GbE disable configuration) for 82577/8/9 devices. After further review, it was found such a reset can cause the 82579 to confuse which version of 82579 it actually is and broke LPLU on all 82577/8/9 devices. The workaround during an S0->Sx transition on 82579 (instead of resetting the PHY) is to restart auto-negotiation after the OEM bits are configured; the restart of auto-negotiation activates the new OEM bits as does the reset. With 82577/8, the reset is changed to a generic reset which fixes the LPLU bits getting set wrong. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-04-04e1000e: Guarantee descriptor writeback flush success.Matthew Vick1-0/+17
In rare circumstances, a descriptor writeback flush may not work if it arrives on a specific clock cycle as a writeback request is going out. Signed-off-by: Matthew Vick <matthew.vick@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-04-04e1000e: prevent oops when adapter is being closed and reset simultaneouslyBruce Allan2-0/+15
When the adapter is closed while it is simultaneously going through a reset, it can cause a null-pointer dereference when the two different code paths simultaneously cleanup up the Tx/Rx resources. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-04-04ixgbe: driver fix for link flapMultanen, Eric W1-84/+80
Fix up code so that changes in DCB settings are detected only when ixgbe_dcbnl_set_all is called. Previously, a series of 'change' commands followed by a call to ixgbe_dcbnl_set_all() would always be handled as a HW change - even if the net change was zero. This patch checks for this case of no actual change and skips going through the HW set process. Without this fix, the link could reset and result in a link flap. The core change in this patch is to check for changes in the ixgbe_copy_dcb_cfg() routine - and return a bitmask of detected changes. The other places where changes were detected previously can be removed. Signed-off-by: Eric Multanen <eric.w.multanen@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-03-28ixgbe: update version numberDon Skidmore1-2/+2
Update the driver version number to better match version of out of tree driver that has similar functionality. Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-03-28ixgbe: fix typo in enumeration nameDon Skidmore1-1/+1
This was pointed out to me by Xiaojun Zhang on Source Forge. CC: Xiaojun Zhang <zhangxiaojun@sourceforge.net> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-03-28intel: make wired ethernet driver message level consistent (rev2)stephen hemminger7-13/+35
Dan Carpenter noticed that ixgbevf initial default was different than the rest. But the problem is broader than that, only one Intel driver (ixgb) was doing it almost right. The convention for default debug level should be consistent among Intel drivers and follow established convention. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-03-28e1000: fix vlan processing regressionJiri Pirko1-13/+22
This patch fixes a regression introduced by commit "e1000: do vlan cleanup (799d531)". Apparently some e1000 chips (not mine) are sensitive about the order of setting vlan filter and vlan stripping/inserting functionality. So this patch changes the order so it's the same as before vlan cleanup. Reported-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Jiri Pirko <jpirko@redhat.com> Tested-by: Ben Greear <greearb@candelatech.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-03-21Merge branch 'kmap_atomic' of git://github.com/congwang/linuxLinus Torvalds2-11/+6
Pull kmap_atomic cleanup from Cong Wang. It's been in -next for a long time, and it gets rid of the (no longer used) second argument to k[un]map_atomic(). Fix up a few trivial conflicts in various drivers, and do an "evil merge" to catch some new uses that have come in since Cong's tree. * 'kmap_atomic' of git://github.com/congwang/linux: (59 commits) feature-removal-schedule.txt: schedule the deprecated form of kmap_atomic() for removal highmem: kill all __kmap_atomic() [swarren@nvidia.com: highmem: Fix ARM build break due to __kmap_atomic rename] drbd: remove the second argument of k[un]map_atomic() zcache: remove the second argument of k[un]map_atomic() gma500: remove the second argument of k[un]map_atomic() dm: remove the second argument of k[un]map_atomic() tomoyo: remove the second argument of k[un]map_atomic() sunrpc: remove the second argument of k[un]map_atomic() rds: remove the second argument of k[un]map_atomic() net: remove the second argument of k[un]map_atomic() mm: remove the second argument of k[un]map_atomic() lib: remove the second argument of k[un]map_atomic() power: remove the second argument of k[un]map_atomic() kdb: remove the second argument of k[un]map_atomic() udf: remove the second argument of k[un]map_atomic() ubifs: remove the second argument of k[un]map_atomic() squashfs: remove the second argument of k[un]map_atomic() reiserfs: remove the second argument of k[un]map_atomic() ocfs2: remove the second argument of k[un]map_atomic() ntfs: remove the second argument of k[un]map_atomic() ...
2012-03-20net: remove the second argument of k[un]map_atomic()Cong Wang2-10/+6
Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Cong Wang <amwang@redhat.com>
2012-03-20ixgbe: Fix issues with SR-IOV loopback when flow control is disabledAlexander Duyck1-1/+8
This patch allows us to avoid a Tx hang when SR-IOV is enabled. This hang can be triggered by sending small packets at a rate that was triggering Rx missed errors from the adapter while the internal Tx switch and at least one VF are enabled. This was all due to the fact that under heavy stress the Rx FIFO never drained below the flow control high water mark. This resulted in the Tx FIFO being head of line blocked due to the fact that it relies on the flow control high water mark to determine when it is acceptable for the Tx to place a packet in the Rx FIFO. The resolution for this is to set the FCRTH value to the RXPBSIZE - 32 so that even if the ring is almost completely full we can still place Tx packets on the Rx ring and drop incoming Rx traffic if we do not have sufficient space available in the Rx FIFO. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Sibai Li <sibai.li@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-03-20Merge branch 'master' of ↵David S. Miller6-1106/+1286
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next
2012-03-20ixgbe: fix namespace issues when FCoE/DCB is not enabledJeff Kirsher4-902/+945
Resolve namespace issues when FCoE or DCB is not enabled. The issue is with certain configurations we end up with namespace problems. A simple example: ixgbe_main.c - defines func A() - uses func A() ixgbe_fcoe.c - uses func A() ixgbe.h - has prototype for func A() For default (FCoE included) all is good. But when it isn't the namespace checker complains about how func A() could be static. To resolve this, created a ixgbe_lib file to contain functions used by DCB/FCoE and their helper functions so that they are always in namespace whether or not DCB/FCoE is enabled. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
2012-03-20igbvf: Use ETH_ALENJoe Perches2-9/+2
Remove an unnecessary #define and use memcpy instead of a loop to copy an ethernet address. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-03-20ixgbe: Correct flag values set by ixgbe_fix_featuresAlexander Duyck3-61/+54
This patch replaces the variable name data with the variable name features for ixgbe_fix_features and ixgbe_set_features. This helps to make some issues more obvious such as the fact that we were disabling Rx VLAN tag stripping when we should have been forcing it to be enabled when DCB is enabled. In addition there was deprecated code present that was disabling the LRO flag if we had the itr value set too low. I have updated this logic so that we will now allow the LRO flag to be set, but will not enable RSC until the rx-usecs value is high enough to allow enough time for Rx packet coalescing. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-03-19ixgbe: Add support for enabling UDP RSS via the ethtool rx-flow-hash commandAlexander Duyck3-1/+160
This patch adds support for enabling or disabling UDP RSS via the ethtool -N rx-flow-hash command. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-03-19ixgbe: Whitespace cleanupsAlexander Duyck1-10/+7
This patch contains several fixes for formatting in regards to whitespace. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-03-19ixgbe: Two minor fixes for RSS and FDIR set queues functionsAlexander Duyck1-3/+1
This change fixes two minor issues. The first was the fact that we were setting the return value to false twice in the set_rss_queues function. The second is the fact that we should have been using "min_t(int," instead of "min((int)" in set_fdir_queues. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-03-19ixgbe: drop err_eeprom tag which is at same location as err_sw_initAlexander Duyck1-3/+2
The err_eeprom and err_sw_init tags both go to the same location. So instead of maintaining two tags this patch combines them so we only use err_sw_init. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-03-19ixgbe: Move poll routine in order to improve readabilityAlexander Duyck1-49/+49
This change relocates the ixgbe_poll routine so it is right next to the interrupt routine that schedules and calls it. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-03-19ixgbe: cleanup logic for the service timer and VF hang detectionAlexander Duyck1-19/+10
This change just cleans up some of the logic in the service_timer function so that we can avoid unnecessary swapping of the ready value between true to false and back to true. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-03-19ixgbe: Update layout of ixgbe_ring structure to improve cache performanceAlexander Duyck1-9/+9
This change makes it so that only the 2nd cache line in the ring structure should see frequent updates. The advantage to this is that it should reduce the amount of cross CPU cache bouncing since only the 2nd cache line will be changing between most network transactions. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-03-19ixgbe: Store Tx flags and protocol information to tx_buffer soonerAlexander Duyck3-51/+51
This change makes it so that we store the tx_flags and protocol information to the tx_buffer_info structure sooner. This allows us to avoid unnecessary read/write transactions since we are placing the data in the final location earlier. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-03-17ixgbe: always write DMA for single_mapped value with skbAlexander Duyck2-118/+153
This change makes it so that we always write the DMA address for the skb itself on the same tx_buffer struct that the skb is written on. This way we don't need the MAPPED_AS_PAGE flag and we always know it will be the first DMA value that we will have to unmap. In addition I have found an issue in which we were leaking a DMA mapping if the value happened to be 0 which is possible on some platforms. In order to resolve that I have updated the transmit path to use the length instead of the DMA mapping in order to determine if a mapping is actually present. One other tweak in this patch is that it only writes the olinfo information on the first descriptor. As it turns out it isn't necessary to write it for anything but the first descriptor so there is no need to carry it forward. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-04 04:59:20 +0300