kernel/git/stable/linux-stable.git/drivers/net/ixgbe, branch linux-2.6.36.y

ixgbe: fix for 82599 erratum on Header Splitting

2011-02-17T22:47:16+00:00

commit a124339ad28389093ed15eca990d39c51c5736cc upstream. We have found a hardware erratum on 82599 hardware that can lead to unpredictable behavior when Header Splitting mode is enabled. So we are no longer enabling this feature on affected hardware. Please see the 82599 Specification Update for more information. Signed-off-by: Don Skidmore Tested-by: Stephen Ko Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman

e100/e1000/igb/ixgb*: Add missing read memory barrier

2010-08-09T03:02:45+00:00

Based on patches from Sonny Rao and Milton Miller... Combined the patches to fix up clean_tx_irq and clean_rx_irq. The PowerPC architecture does not require loads to independent bytes to be ordered without adding an explicit barrier. In ixgbe_clean_rx_irq we load the status bit then load the packet data. With packet split disabled if these loads go out of order we get a stale packet, but we will notice the bad sequence numbers and drop it. The problem occurs with packet split enabled where the TCP/IP header and data are in different descriptors. If the reads go out of order we may have data that doesn't match the TCP/IP header. Since we use hardware checksumming this bad data is never verified and it makes it all the way to the application. This bug was found during stress testing and adding this barrier has been shown to fix it. The bug can manifest as a data integrity issue (bad payload data) or as a BUG in skb_pull(). This was a nasty bug to hunt down, if people agree with the fix I think it's a candidate for stable. Previously Submitted to e1000-devel only for ixgbe http://marc.info/?l=e1000-devel&m=126593062701537&w=3 We've now seen this problem hit with other device drivers (e1000e mostly) So I'm resubmitting with fixes for other Intel Device Drivers with similar issues. CC: Milton Miller CC: Anton Blanchard CC: Sonny Rao CC: stable Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

ixgbe: fix build error with FCOE_CONFIG without DCB_CONFIG

2010-08-09T03:02:44+00:00

Building ixgbe without DCB_CONFIG and FCOE_CONFIG will cause a build error. This resolves the build error by wrapping the fcoe.up in CONFIG_IXGBE_DCB ifdefs. Also frames were being priority VLAN tagged even without DCB enabled. This fixes this so that 8021Q priority tags are only added with DCB actually enabled. Reported-by: divya Reported-by: Jon Mason Signed-off-by: John Fastabend Tested-by: Stephen Ko Tested-by: Ross Brattain Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6

2010-07-28T04:01:35+00:00

Conflicts: drivers/net/bnx2x_main.c Merge bnx2x bug fixes in by hand... :-/ Signed-off-by: David S. Miller

ixgbe: potential null dereference

2010-07-28T03:48:19+00:00

The e_dev_err() macro dereferences "adapter" which is NULL here. Signed-off-by: Dan Carpenter Acked-by: Jeff Kirsher Signed-off-by: David S. Miller

ixgbe: priority tagging FCoE frames without FCoE offload

2010-07-27T20:18:13+00:00

The DCB user priority for FCoE is available regardless of whether FCoE offload is enabled (IXGBE_FLAG_FCOE_ENABLED bit is set). This allows proper DCB user priority tagging for FCoE traffic on both 82598 and 82599 devices. Signed-off-by: Yi Zou Signed-off-by: John Fastabend Tested-by: Ross Brattain Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

ixgbe: fix ethtool stats

2010-07-25T03:43:19+00:00

In latest changes about 64bit stats on 32bit arches, [commit 28172739f0a276eb8 (net: fix 64 bit counters on 32 bit arches)], I missed ixgbe uses a bit of magic in its ixgbe_gstrings_stats definition. IXGBE_NETDEV_STAT() must now assume offsets relative to rtnl_link_stats64, not relative do dev->stats. As a bonus, we also get 64bit stats on ethtool -S Signed-off-by: Eric Dumazet Tested-by: Stephen Ko Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

ixgbe/igb: catch invalid VF settings

2010-07-21T20:48:55+00:00

Some ixgbe cards put an invalid VF device ID in the PCIe SR-IOV capability. The ixgbe driver is only valid for PFs or non SR-IOV hardware. It seems that the same problem could occur on igb hardware as well, so if we discover we are trying to initialize a VF in ixbge_probe or igb_probe, print an error and exit. Based on a patch for ixgbe from Chris Wright . Signed-off-by: Andy Gospodarek Cc: Chris Wright Acked-by: Chris Wright Acked-by: Greg Rose Signed-off-by: David S. Miller

ixgbe: fix version string for ixgbe

2010-07-20T03:23:38+00:00

Bump the version string to better reflect what is in the driver. Signed-off-by: Don Skidmore Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

ixgbe: use GFP_ATOMIC when allocating FCoE DDP context from the dma pool

2010-07-20T03:23:37+00:00

The FCoE protocol stack may hold a lock when this gets called. Signed-off-by: Yi Zou Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller