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

ixgbe: fix for 82599 erratum on Header Splitting

2011-03-31T18:58:20+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 Signed-off-by: Andi Kleen

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

2010-08-13T20:30:49+00:00

commit 2d0bb1c1f4524befe9f0fcf0d0cd3081a451223f upstream. 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 Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

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

net: decreasing real_num_tx_queues needs to flush qdisc

2010-07-03T04:59:07+00:00

Reducing real_num_queues needs to flush the qdisc otherwise skbs with queue_mappings greater then real_num_tx_queues can be sent to the underlying driver. The flow for this is, dev_queue_xmit() dev_pick_tx() skb_tx_hash() => hash using real_num_tx_queues skb_set_queue_mapping() ... qdisc_enqueue_root() => enqueue skb on txq from hash ... dev->real_num_tx_queues -= n ... sch_direct_xmit() dev_hard_start_xmit() ndo_start_xmit(skb,dev) => skb queue set with old hash skbs are enqueued on the qdisc with skb->queue_mapping set 0 < queue_mappings < real_num_tx_queues. When the driver decreases real_num_tx_queues skb's may be dequeued from the qdisc with a queue_mapping greater then real_num_tx_queues. This fixes a case in ixgbe where this was occurring with DCB and FCoE. Because the driver is using queue_mapping to map skbs to tx descriptor rings we can potentially map skbs to rings that no longer exist. Signed-off-by: John Fastabend Tested-by: Ross Brattain Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

ixgbe: skip non IPv4 packets in ATR filter

2010-06-30T06:12:41+00:00

In driver ixgbe, ixgbe_atr may cause crashes for non-ipv4 packets. Just add a test to check skb->protocol. It may crash on short packets due to ip_hdr() access. Signed-off-by: Guillaume Gaudonville Acked-by: Peter P Waskiewicz Jr Signed-off-by: Don Skidmore Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

ixgbe: disable tx engine before disabling tx laser

2010-06-30T06:12:40+00:00

Disabling the tx laser while receiving DMA requests can hang the device. After this occurs the device is in a bad state. The GPIO bit never clears when PCI master access is disabled and a reboot is required to get the device in a good state again. Signed-off-by: John Fastabend Acked-by: Peter P Waskiewicz Jr Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

ixgbe: fix panic when shutting down system with WoL enabled

2010-06-30T06:12:39+00:00

This patch added to 2.6.34: commit 5f6c01819979afbfec7e0b15fe52371b8eed87e8 Author: Jesse Brandeburg Date: Wed Apr 14 16:04:23 2010 -0700 ixgbe: fix bug with vlan strip in promsic mode among other things added a function called ixgbe_vlan_filter_enable. This new function wants to access and set some rx_ring parameters, but adapter->rx_ring has already been freed. This simply moves the free until after the access and makes __ixgbe_shutdown look more like ixgbe_remove. Signed-off-by: Andy Gospodarek Acked-by: Jesse Brandeburg Tested-by: Emil Tantilov Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

ixgbe: add comment on SFP+ ID for Active DA

2010-06-16T21:47:30+00:00

These comments were forgotten in the initial patch to add this functionality. This patch corrects that. Signed-off-by: Don Skidmore Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

ixgbe: fix automatic LRO/RSC settings for low latency

2010-06-14T01:20:53+00:00

This patch added to 2.6.34: commit f8d1dcaf88bddc7f282722ec1fdddbcb06a72f18 Author: Jesse Brandeburg Date: Tue Apr 27 01:37:20 2010 +0000 ixgbe: enable extremely low latency introduced a feature where LRO (called RSC on the hardware) was disabled automatically when setting rx-usecs to 0 via ethtool. Some might not like the fact that LRO was disabled automatically, but I'm fine with that. What I don't like is that LRO/RSC is automatically enabled when rx-usecs is set >0 via ethtool. This would certainly be a problem if the device was used for forwarding and it was determined that the low latency wasn't needed after the device was already forwarding. I played around with saving the state of LRO in the driver, but it just didn't seem worthwhile and would require a small change to dev_disable_lro() that I did not like. This patch simply leaves LRO disabled when setting rx-usecs >0 and requires that the user enable it again. An extra informational message will also now appear in the log so users can understand why LRO isn't being enabled as they expect. Inconsistency of LRO setting first noticed by Stanislaw Gruszka. Signed-off-by: Andy Gospodarek CC: Stanislaw Gruszka CC: stable@kernel.org Tested-by: Stephen Ko Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

ixgbe: fix for race with 8259(8|9) during shutdown

2010-06-14T01:20:52+00:00

There is a small window where the watchdog could be running as the interface is brought down on a NIC with two ports wired back to back. If ixgbe_update_status is then called can lead to a panic. This patch allows the update to bail if we are in that condition. This issue was orignally reported and fix proposed by Akihiko Saitou. CC: Akihiko Saitou Signed-off-by: Don Skidmore Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller