linux-stable.git/drivers/net/ethernet/intel, branch v3.2.32

e1000: fix lockdep splat in shutdown handler

2012-10-17T02:50:10+00:00

commit 3a3847e007aae732d64d8fd1374126393e9879a3 upstream.

As reported by Steven Rostedt, e1000 has a lockdep splat added
during the recent merge window.  The issue is that
cancel_delayed_work is called while holding our private mutex.

There is no reason that I can see to hold the mutex during pci
shutdown, it was more just paranoia that I put the mutex_lock
around the call to e1000_down.

In a quick survey lots of drivers handle locking differently when
being called by the pci layer.  The assumption here is that we
don't need the mutexes' protection in this function because
the driver could not be unloaded while in the shutdown handler
which is only called at reboot or poweroff.

Reported-by: Steven Rostedt 
Signed-off-by: Jesse Brandeburg 
Tested-by: Steven Rostedt 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

e1000e: DoS while TSO enabled caused by link partner with small MSS

2012-09-19T14:04:37+00:00

commit d821a4c4d11ad160925dab2bb009b8444beff484 upstream.

With a low enough MSS on the link partner and TSO enabled locally, the
networking stack can periodically send a very large (e.g.  64KB) TCP
message for which the driver will attempt to use more Tx descriptors than
are available by default in the Tx ring.  This is due to a workaround in
the code that imposes a limit of only 4 MSS-sized segments per descriptor
which appears to be a carry-over from the older e1000 driver and may be
applicable only to some older PCI or PCIx parts which are not supported in
e1000e.  When the driver gets a message that is too large to fit across the
configured number of Tx descriptors, it stops the upper stack from queueing
any more and gets stuck in this state.  After a timeout, the upper stack
assumes the adapter is hung and calls the driver to reset it.

Remove the unnecessary limitation of using up to only 4 MSS-sized segments
per Tx descriptor, and put in a hard failure test to catch when attempting
to check for message sizes larger than would fit in the whole Tx ring.
Refactor the remaining logic that limits the size of data per Tx descriptor
from a seemingly arbitrary 8KB to a limit based on the dynamic size of the
Tx packet buffer as described in the hardware specification.

Also, fix the logic in the check for space in the Tx ring for the next
largest possible packet after the current one has been successfully queued
for transmit, and use the appropriate defines for default ring sizes in
e1000_probe instead of magic values.

This issue goes back to the introduction of e1000e in 2.6.24 when it was
split off from e1000.

Reported-by: Ben Hutchings 
Signed-off-by: Bruce Allan 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2:
 - Adjust context
 - Adjust for use of net_device vs e1000_ring parameter]
Signed-off-by: Ben Hutchings

e1000e: NIC goes up and immediately goes down

2012-08-19T17:15:32+00:00

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 
Signed-off-by: Tushar Dave 
CC: Marcelo Ricardo Leitner 
Tested-by: Aaron Brown 
Signed-off-by: Peter P Waskiewicz Jr 
Signed-off-by: Ben Hutchings

e1000: add dropped DMA receive enable back in for WoL

2012-08-19T17:15:26+00:00

commit b868179c47e9e8eadcd04c1f3105998e528988a3 upstream.

Commit d5bc77a223b0e9b9dfb002048d2b34a79e7d0b48 broke Wake-on-LAN by
inadvertently dropping the enabling of DMA receives.

Restore the enabling of DMA receives for WoL.

This is applicable to 3.1+ stable trees.

Reported-by: Tobias Klausmann 
Signed-off-by: Dean Nelson 
Tested-by: Tobias Klausmann 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Ben Hutchings

e1000e: Correct link check logic for 82571 serdes

2012-07-25T03:11:23+00:00

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 
Signed-off-by: Tushar Dave 
Reviewed-by: Bruce Allan 
Tested-by: Jeff Pieper 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Ben Hutchings

e1000e: Remove special case for 82573/82574 ASPM L1 disablement

2012-07-04T04:44:12+00:00

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 
Tested-by: Jeff Pieper 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Ben Hutchings

e1000e: Disable ASPM L1 on 82574

2012-07-04T04:44:12+00:00

commit id d4a4206ebbaf48b55803a7eb34e330530d83a889

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 
Cc: "Wyborny, Carolyn" 
Cc: Nix 
Link: https://lkml.org/lkml/2012/3/19/362
Tested-by: Jeff Pieper 
[Jeff Kirsher: Backport to 3.2-3.4 kernels]
Signed-off-by: Jeff Kirsher 
Signed-off-by: Ben Hutchings

e1000: Prevent reset task killing itself.

2012-05-20T21:56:52+00:00

commit 8ce6909f77ba1b7bcdea65cc2388fd1742b6d669 upstream.

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

Signed-off-by: Tushar Dave 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

e1000e: Avoid wrong check on TX hang

2012-04-02T16:52:52+00:00

commit 09357b00255c233705b1cf6d76a8d147340545b8 upstream.

Based on the original patch submitted my Michael Wang
.
Descriptors may not be write-back while checking TX hang with flag
FLAG2_DMA_BURST on.
So when we detect hang, we just flush the descriptor and detect
again for once.

-v2 change 1 to true and 0 to false and remove extra ()

CC: Michael Wang 
CC: Flavio Leitner 
Acked-by: Jesse Brandeburg 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

igb: fix vf lookup

2012-02-20T20:46:13+00:00

commit 0629292117572a60465f38cdedde2f8164c3df0b upstream.

Recent addition of code to find already allocated VFs failed to take
account that systems with 2 or more multi-port SR-IOV capable controllers
might have already enabled VFs.  Make sure that the VFs the function is
finding are actually subordinate to the particular instance of the adapter
that is looking for them and not subordinate to some device that has
previously enabled SR-IOV.

This is applicable to 3.2+ kernels.

Reported-by: David Ahern 
Signed-off-by: Greg Rose 
Tested-by: Robert E Garrett 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman