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

e1000: fix screaming IRQ

2010-12-14T22:40:14+00:00

commit ab08853fab2093e5c6f5de56827a4c93dce4b055 upstream. VMWare reports that the e1000 driver has a bug when bringing down the interface, such that interrupts are not disabled in the hardware but the driver stops reporting that it consumed the interrupt. The fix is to set the driver's "down" flag later in the routine, after all the timers and such have exited, preventing the interrupt handler from being called and exiting early without handling the interrupt. CC: Anupam Chanda Signed-off-by: Jesse Brandeburg Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller 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

e1000: Fix message logging defect

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

commit 675ad47375c76a7c3be4ace9554d92cd55518ced removed the capability to use ethtool.set_msglevel to control the types of messages emitted by the driver. That commit should probably be reverted. If not, then this patch fixes a message logging defect introduced by converting a printk without KERN_ to e_info. This also reduces text by about 200 bytes. Signed-off-by: Joe Perches Tested-by: Emil Tantilov Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

ixgb and e1000: Use new function for copybreak tests

2010-05-14T10:06:19+00:00

There appears to be an off-by-1 defect in the maximum packet size copied when copybreak is speified in these modules. The copybreak module params are specified as: "Maximum size of packet that is copied to a new buffer on receive" The tests are changed from "< copybreak" to "<= copybreak" and moved into new static functions for readability. Signed-off-by: Joe Perches Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

e1000: cleanup unused parameters

2010-05-14T10:06:19+00:00

During the cleanup pass after the removal of e1000e hardware from e1000 some parameters were missed. Remove them because it is just dead code. Signed-off-by: Jesse Brandeburg Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

e1000: fix WARN_ON with mac-vlan

2010-05-14T10:06:18+00:00

When adding more than 14 mac-vlan adapters on e1000 the driver would fire a WARN_ON when adding the 15th. The WARN_ON in this case is completely un-necessary, as the code below the WARN_ON is directly handling the value the WARN_ON triggered on. CC: Jiri Pirko Signed-off-by: Jesse Brandeburg Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

drivers/net: Remove unnecessary returns from void function()s

2010-05-14T07:19:28+00:00

This patch removes from drivers/net/ all the unnecessary return; statements that precede the last closing brace of void functions. It does not remove the returns that are immediately preceded by a label as gcc doesn't like that. It also does not remove null void functions with return. Done via: $ grep -rP --include=*.[ch] -l "return;\n}" net/ | \ xargs perl -i -e 'local $/ ; while (<>) { s/\n[ \t\n]+return;\n}/\n}/g; print; }' with some cleanups by hand. Compile tested x86 allmodconfig only. Signed-off-by: Joe Perches Signed-off-by: David S. Miller

e1000/e1000e: implement a simple interrupt moderation

2010-05-06T04:15:32+00:00

Back before e1000-7.3.20, the e1000 driver had a simple algorithm that managed interrupt moderation. The driver was updated in 7.3.20 to have the new "adaptive" interrupt moderation but we have customer requests to redeploy the old way as an option. This patch adds the old functionality back. The new functionality can be enabled via module parameter or at runtime via ethtool. Module parameter: (InterruptThrottleRate=4) to use this new moderation method. Ethtool method: ethtool -C ethX rx-usecs 4 Signed-off-by: Jesse Brandeburg Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

e1000: Use netdev_, pr_ and dev_

2010-04-28T00:05:03+00:00

This patch is an alternative to similar patch provided by Joe Perches. Substitute DPRINTK macro for e_ that uses netdev_ and dev_ similar to e1000e. - Convert printk to pr_ where applicable. - Use common #define pr_fmt for the driver. - Use dev_ for displaying text in parts of the driver where the interface name is not assigned (like e1000_param.c). - Better align test with the new macros. CC: Joe Perches Signed-off-by: Emil Tantilov Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

e1000: use DMA API instead of PCI DMA functions

2010-04-27T23:29:49+00:00

Signed-off-by: Nicholas Nunley Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller