[E1000-devel] Intel ethernet card strange behaviour
Hi all, I need a help with following issue. I have a board with six Ethernet cards (all e1000). Two of them are currently used (eth0, eth2). If I do ifdown eth0 and then ifup eth0 it lasts at least 30s (ping reports destination host unreachable) until the card starts send/receive packets again. However, whole the time it is reported as up. If I do the same with another Ethernet card eth2 the delay is significantly smaller. Hardware background: - ATCA platform - eth cards are Intel 82546 - eth0 is situated on expansion PMC board - eth2 is integrated (connected to backplane) Does anyone have any idea why eth0 is so delayed? Thanks a lot. Michal Filka -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] Intel ethernet card strange behaviour
Filka Michal wrote: Hi all, I need a help with following issue. I have a board with six Ethernet cards (all e1000). Two of them are currently used (eth0, eth2). If I do ifdown eth0 and then ifup eth0 it lasts at least 30s (ping reports destination host unreachable) until the card starts send/receive packets again. However, whole the time it is reported as up. If I do the same with another Ethernet card eth2 the delay is significantly smaller. Hardware background: - ATCA platform - eth cards are Intel 82546 - eth0 is situated on expansion PMC board - eth2 is integrated (connected to backplane) Does anyone have any idea why eth0 is so delayed? sounds like that problem port has spanning tree enabled? -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] e1000 watchdog timer fails to start after ethool settings change
added maintainer's list On Wed, 15 Apr 2009, Ed Swierk wrote: A recent patch to e1000, intended to avoid a race in the interrupt code, seems to prevent the watchdog timer from resuming properly. It neuters the effect of /* fire a link change interrupt to start the watchdog */ ew32(ICS, E1000_ICS_LSC); in e1000_up() when the __E1000_RESETTING flag is set, for example when invoked by e1000_set_settings(). Ugh, ethtool, my old nemesis. The result is that running ethtool -s eth0 autoneg on in Qemu with an emulated e1000 NIC causes the kernel to stop noticing link status changes, leaving the link down until I prod the driver with ifconfig eth0 down; ifconfig eth0 up. Wow, thanks very much for reporting this, it is a pretty subtle bug that I'm sure wasn't too easy to find. I've got to think some on how to fix this and I hope to have a patch in the next few days. Would you agree not very high priority? My guess is this may be related to the people that reported vmware failing with this same change. Why it doesn't occur on real physical hardware will be interesting to find out as well. Here is the patch causing the bug: From: Jesse Brandeburg jesse.brandeb...@x A nasty bug was found where an MTU change (or anything else that caused a reset) could race with the interrupt code. The interrupt code was entered by a shared interrupt during the MTU change. This change prevents the interrupt code from running while the driver is in the middle of its reset path. Signed-off-by: Jesse Brandeburg jesse.brandeb...@x --- drivers/net/e1000/e1000_main.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c index 26474c9..c986978 100644 --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -31,7 +31,7 @@ char e1000_driver_name[] = e1000; static char e1000_driver_string[] = Intel(R) PRO/1000 Network Driver; -#define DRV_VERSION 7.3.20-k3-NAPI +#define DRV_VERSION 7.3.21-k3-NAPI const char e1000_driver_version[] = DRV_VERSION; static const char e1000_copyright[] = Copyright (c) 1999-2006 Intel Corporation.; @@ -3712,7 +3712,7 @@ static irqreturn_t e1000_intr(int irq, void *data) struct e1000_hw *hw = adapter-hw; u32 rctl, icr = er32(ICR); - if (unlikely(!icr)) + if (unlikely((!icr) || test_bit(__E1000_RESETTING, adapter-flags))) return IRQ_NONE; /* Not our interrupt */ /* IMS will not auto-mask if INT_ASSERTED is not set, and if it is Undoing the patch fixes the problem on a Qemu emulated e1000 NIC: Index: linux-2.6.29.1/drivers/net/e1000/e1000_main.c === --- linux-2.6.29.1.orig/drivers/net/e1000/e1000_main.c +++ linux-2.6.29.1/drivers/net/e1000/e1000_main.c @@ -3712,7 +3712,7 @@ static irqreturn_t e1000_intr(int irq, v struct e1000_hw *hw = adapter-hw; u32 rctl, icr = er32(ICR); - if (unlikely((!icr) || test_bit(__E1000_RESETTING, adapter-flags))) + if (unlikely(!icr)) return IRQ_NONE; /* Not our interrupt */ /* IMS will not auto-mask if INT_ASSERTED is not set, and if it is --- Of course this leaves the original problem unfixed; hopefully someone can suggest a better solution. Give us a few days, I think we can come up with something. Jesse -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
[E1000-devel] reigned cowling keepsake determminacy
lizard unreceptive hyypotensive deforciant -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] [PATCH] ixgbe: missing parentheses
(cc netdev) On Thu, 16 Apr 2009 23:05:00 +0200 Roel Kluin roel.kl...@gmail.com wrote: `!' has a higher precedence than `' Signed-off-by: Roel Kluin roel.kl...@gmail.com --- diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c index febde45..49a9037 100644 --- a/drivers/net/ixgbe/ixgbe_main.c +++ b/drivers/net/ixgbe/ixgbe_main.c @@ -3946,7 +3946,7 @@ static void ixgbe_sfp_config_module_task(struct work_struct *work) } hw-mac.ops.setup_sfp(hw); - if (!adapter-flags IXGBE_FLAG_IN_SFP_LINK_TASK) + if (!(adapter-flags IXGBE_FLAG_IN_SFP_LINK_TASK)) /* This will also work for DA Twinax connections */ schedule_work(adapter-multispeed_fiber_task); adapter-flags = ~IXGBE_FLAG_IN_SFP_MOD_TASK; This is fixed in linux-next, but hasn't been pushed to Linus yet. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] [PATCH] ixgbe: missing parentheses
On Thursday, April 16, 2009 Andrew Morton wrote: (cc netdev) On Thu, 16 Apr 2009 23:05:00 +0200 Roel Kluin roel.kl...@gmail.com wrote: `!' has a higher precedence than `' Signed-off-by: Roel Kluin roel.kl...@gmail.com --- diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c index febde45..49a9037 100644 --- a/drivers/net/ixgbe/ixgbe_main.c +++ b/drivers/net/ixgbe/ixgbe_main.c @@ -3946,7 +3946,7 @@ static void ixgbe_sfp_config_module_task(struct work_struct *work) } hw-mac.ops.setup_sfp(hw); -if (!adapter-flags IXGBE_FLAG_IN_SFP_LINK_TASK) +if (!(adapter-flags IXGBE_FLAG_IN_SFP_LINK_TASK)) /* This will also work for DA Twinax connections */ schedule_work(adapter-multispeed_fiber_task); adapter-flags = ~IXGBE_FLAG_IN_SFP_MOD_TASK; This is fixed in linux-next, but hasn't been pushed to Linus yet. Yes, Dave has this fix in his net-next-2.6 tree. Dave - Can we pull this fix into net-2.6? Cheers, Jeff -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] [PATCH] ixgbe: missing parentheses
From: Kirsher, Jeffrey T jeffrey.t.kirs...@intel.com Date: Thu, 16 Apr 2009 14:25:44 -0700 Dave - Can we pull this fix into net-2.6? Just toss me a patch and I'll apply it directly. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] [PATCH] ixgbe: missing parentheses
From: Andrew Morton a...@linux-foundation.org Date: Thu, 16 Apr 2009 14:16:10 -0700 @@ -3946,7 +3946,7 @@ static void ixgbe_sfp_config_module_task(struct work_struct *work) } hw-mac.ops.setup_sfp(hw); -if (!adapter-flags IXGBE_FLAG_IN_SFP_LINK_TASK) +if (!(adapter-flags IXGBE_FLAG_IN_SFP_LINK_TASK)) /* This will also work for DA Twinax connections */ schedule_work(adapter-multispeed_fiber_task); adapter-flags = ~IXGBE_FLAG_IN_SFP_MOD_TASK; This is fixed in linux-next, but hasn't been pushed to Linus yet. If I recall correctly, this got submitted to me as a net-next-2.6 only patch, which obviously isn't correct. Intel folks, please resubmit this to me for net-2.6 too, thanks. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
[E1000-devel] e1000e not working on 2.6.29.1
Hi, I updated to kernel 2.6.29.1 (from 2.6.22) yesterday and my Intel 82566MM fails to work now (eth0 is not recognized). First, I noticed that the new kernel uses e1000e for this controller rather than e1000, but I get the following in dmesg: e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k6 e1000e: Copyright (c) 1999-2008 Intel Corporation. e1000e :00:19.0: PCI INT A - GSI 20 (level, low) - IRQ 20 e1000e :00:19.0: setting latency timer to 64 :00:19.0: :00:19.0: Failed to initialize MSI interrupts. Falling back to legacy interrupts. :00:19.0: :00:19.0: Invalid MAC Address: 00:00:00:00:00:00 e1000e :00:19.0: PCI INT A disabled e1000e: probe of :00:19.0 failed with error -5 I searched for this issue, and came up with similar problems with e1000e but they involved checksum errors etc. I couldn't find any solution for the above. I tried with CONFIG_PCI_MSI enabled but then I get the following messages and eth0 is still not recognized. e1000e: Unknown symbol pci_disable_msi e1000e: Unknown symbol pci_enable_msi e1000e: Unknown symbol pci_enable_msix e1000e: Unknown symbol pci_disable_msi I'm using a Thinkpad T61p, and following is the ouput from lspci: 00:00.0 Host bridge: Intel Corporation Mobile Memory Controller Hub (rev 0c) 00:01.0 PCI bridge: Intel Corporation Mobile PCI Express Root Port (rev 0c) 00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network Connection (rev 03) 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 03) 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03) 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03) 00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3) 00:1f.0 ISA bridge: Intel Corporation Mobile LPC Interface Controller (rev 03) 00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 03) 00:1f.2 SATA controller: Intel Corporation Mobile SATA AHCI Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03) 01:00.0 VGA compatible controller: nVidia Corporation Unknown device 040c (rev a1) 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) 05:00.0 Mass storage controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01) 15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6) Note that I can boot into the old kernel (2.6.22) and the ethernet works fine as before. Please let me know if there is a fix for this, or if you need more information. Thanks, Aditya -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] e1000e not working on 2.6.29.1
Aditya Rajgarhia wrote: Hi, I updated to kernel 2.6.29.1 (from 2.6.22) yesterday and my Intel 82566MM fails to work now (eth0 is not recognized). First, I noticed that the new kernel uses e1000e for this controller rather than e1000, but I get the following in dmesg: e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k6 e1000e: Copyright (c) 1999-2008 Intel Corporation. e1000e :00:19.0: PCI INT A - GSI 20 (level, low) - IRQ 20 e1000e :00:19.0: setting latency timer to 64 :00:19.0: :00:19.0: Failed to initialize MSI interrupts. Falling back to legacy interrupts. :00:19.0: :00:19.0: Invalid MAC Address: 00:00:00:00:00:00 e1000e :00:19.0: PCI INT A disabled e1000e: probe of :00:19.0 failed with error -5 please send your .config as config.txt and full output of lspci -vvv as lspci.txt when the driver has failed to load. I searched for this issue, and came up with similar problems with e1000e but they involved checksum errors etc. I couldn't find any solution for this seems like a new issue. the above. I tried with CONFIG_PCI_MSI enabled but then I get the following messages and eth0 is still not recognized. e1000e: Unknown symbol pci_disable_msi e1000e: Unknown symbol pci_enable_msi e1000e: Unknown symbol pci_enable_msix e1000e: Unknown symbol pci_disable_msi that's just a compile error, you have to rebuild both kernel and driver with make -j2 all; make modules_install install snip Note that I can boot into the old kernel (2.6.22) and the ethernet works fine as before. Please let me know if there is a fix for this, or if you need more information. in the old kernel please do ethtool -e eth0 and get the dump of the eeprom and send it to us as ethtool.txt -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] process stuck in sendto() with e1000 NIC
On Sunday, April 12, 2009 Charles-François Natali wrote: Hi, I'm sorry to bother you, but I'm having a weird problem with e1000 NIC, and I think you might be able to help me figure out what's happening - I saw you submitted a patch for a problem dealing with socket buffer a few years ago to the e1000 driver. So here's the story : at work, we have around 300 computers equiped with NICs using e1000 driver. From time to time, we see processes stuck in sendto() when sending multicast trafic on an interface _that has its link down_. First analysis showed that the processes are stuck because their send buffer is full. I tried to read te kernel code, and came to the conclusion that the only place where the process can possibly be stuck is in sock_wait_for_wmem. But why ? Since the socket is created after the interface has lost its link, the driver has called netif_stop_queue, so, when the device tx queue gets full, the packets should be dropped, and the process shouldn't sleep. The only explanation I see is that the socket send buffer gets full before the device txqueue : if there is for example only one process sending on this interface, the device txqueue will never get full and drop packets, so the process it will remain stuck in sock_wait_for_wmem forever. Thank you for reading that far, hopping you wight have an idea of what's going on. Cheers, Charles (adding e1000-devel mailing list) What kernel version and e1000 driver version are you using? Cheers, Jeff -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
