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

e1000: Small packets may get corrupted during padding by HW

2012-09-18T20:32:21+00:00

On PCI/PCI-X HW, if packet size is less than ETH_ZLEN,
packets may get corrupted during padding by HW.
To WA this issue, pad all small packets manually.

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

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

2012-08-30T16:40:22+00:00

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 
Cc: Stable  [2.6.24+]
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller

ixgbe: add missing braces

2012-08-10T23:51:23+00:00

This patch adds missing braces around the 10gig link check to include the check for  KR support.

Signed-off-by: Emil Tantilov 
Reported-by: Sascha Wildner 
Tested-by: Phil Schmitt 
Signed-off-by: Peter P Waskiewicz Jr 
Signed-off-by: David S. Miller

igb: Fix register defines for all non-82575 hardware

2012-08-09T09:36:05+00:00

It looks like the register defines for DCA were never updated after going from
82575 to 82576.  This change addresses that by updating the defines.

Signed-off-by: Alexander Duyck 
Tested-by: Jeff Pieper 
Signed-off-by: Peter P Waskiewicz Jr

e1000e: fix panic while dumping packets on Tx hang with IOMMU

2012-08-09T09:36:05+00:00

This patch resolves a "BUG: unable to handle kernel paging request at ..."
oops while dumping packet data. The issue occurs with IOMMU enabled due to
the address provided by phys_to_virt().

This patch avoids phys_to_virt() by using skb->data and the address of the
pages allocated for Rx.

Signed-off-by: Emil Tantilov 
Tested-by: Jeff Pieper 
Signed-off-by: Peter P Waskiewicz Jr

igb: fix panic while dumping packets on Tx hang with IOMMU

2012-08-09T09:36:05+00:00

This patch resolves a "BUG: unable to handle kernel paging request at ..."
oops while dumping packet data. The issue occurs with IOMMU enabled due to
the address provided by phys_to_virt().

This patch avoids phys_to_virt() by making using skb->data and the address
of the pages allocated for Rx.

Signed-off-by: Emil Tantilov 
Tested-by: Jeff Pieper 
Signed-off-by: Peter P Waskiewicz Jr

igb: add delay to allow igb loopback test to succeed on 8086:10c9

2012-08-07T07:47:51+00:00

Some 8086:10c9 NICs have a problem completing the ethtool loopback test.
The result looks like this:

ethtool -t eth1
The test result is FAIL
The test extra info:
Register test  (offline)         0
Eeprom test    (offline)         0
Interrupt test (offline)         0
Loopback test  (offline)         13
Link test   (on/offline)         0

A bisect clearly points to commit a95a07445ee97a2fef65befafbadcc30ca1bd145.
However that seems to only trigger the bug. While adding some printk the
problem disappeared, so this might be a timing issue. After some trial and
error I discovered that adding a small delay just before igb_write_phy_reg()
in igb_integrated_phy_loopback() allows the loopback test to succeed.
I was unable to figure out the root cause so far but I expect it to be
somewhere in the following executing path
igb_integrated_phy_loopback
->igb_write_phy_reg_igp
  ->igb_write_phy_reg_mdic
    ->igb_acquire_phy_82575
      ->igb_acquire_swfw_sync_82575

The problem could only be observed on 8086:10c9 NICs so far and not all
of them show the behaviour. I did not restrict the workaround to this
type of NIC as it should do no harm to other igb NICs.

With the patch below the loopback test succeeded 500 times in a row
using a NIC that would otherwise fail.

Signed-off-by: Stefan Assmann 
Tested-by: Aaron Brown 
Signed-off-by: Peter P Waskiewicz Jr

e1000e: 82571 Tx Data Corruption during Tx hang recovery

2012-08-07T07:41:36+00:00

A bus trace shows that while executing e1000e_down, TCTL is cleared except
for the PSP bit.  This occurs while in the middle of fetching a TSO packet
since the Tx packet buffer is full at that point. Before the device is
reset, the e1000_watchdog_task starts to run from the middle (it was
apparently pre-empted earlier, although that is not in the trace) and sets
TCTL.EN.  At that point, 82571 transmits the corrupted packet, apparently
because TCTL.MULR was cleared in the middle of fetching a packet, which is
forbidden.

Driver should just clear TCTL.EN in e1000_reset_hw_82571 instead of
clearing the entire register, so as not to change any settings in the
middle of fetching a packet.

Signed-off-by: Tushar Dave 
Tested-by: Aaron Brown 
Signed-off-by: Peter P Waskiewicz Jr

e1000e: NIC goes up and immediately goes down

2012-08-07T07:40:08+00:00

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 
CC: stable  [2.6.38+]
Tested-by: Aaron Brown 
Signed-off-by: Peter P Waskiewicz Jr

igb: don't break user visible strings over multiple lines in igb_ethtool.c

2012-08-04T09:45:07+00:00

Even when they go beyond 80 characters, user visible strings should be
on one line to make them easy to grep for.

Signed-off-by: Jesper Juhl 
Tested-by: Jeff Pieper 
Signed-off-by: Peter P Waskiewicz Jr