>-----Original Message----- >From: Thomas Jarosch [mailto:[email protected]] >Sent: Friday, April 01, 2011 5:33 AM >To: [email protected] >Subject: [E1000-devel] igb: High packet loss on every sixth+ boot > >Hello, > >I'm currently trying to track down an interesting packet loss issue. >The problem occurs with this card (lspci): > >20:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network >Connection (rev 01) >20:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network >Connection (rev 01) > >Every sixth boot or so I get a packet loss of 50% and more. >Disconnecting the cable and reconnecting it solves the issue. > >-------------------------------------------------------------------- >$ ping -s 8192 192.168.111.254 >PING 192.168.111.254 (192.168.111.254) 8192(8220) bytes of data. >8200 bytes from 192.168.111.254: icmp_req=3 ttl=64 time=0.485 ms >8200 bytes from 192.168.111.254: icmp_req=5 ttl=64 time=0.489 ms >8200 bytes from 192.168.111.254: icmp_req=8 ttl=64 time=0.477 ms >^C >--- 192.168.111.254 ping statistics --- >8 packets transmitted, 3 received, 62% packet loss, time 7000ms >-------------------------------------------------------------------- > >Tested with kernel 2.6.34, 2.6.36, 2.6.37 and 2.6.38. > >Detection on boot: >Apr 1 14:06:09 kernel: igb 0000:20:00.0: PCI INT A -> GSI 16 (level, >low) -> IRQ 16 >Apr 1 14:06:09 kernel: igb 0000:20:00.0: Intel(R) Gigabit Ethernet >Network Connection >Apr 1 14:06:09 kernel: igb 0000:20:00.0: eth1: (PCIe:2.5Gb/s:Width x4) >00:1b:21:6e:9c:76 >Apr 1 14:06:09 kernel: igb 0000:20:00.0: eth1: PBA No: e43709-005 >Apr 1 14:06:09 kernel: igb 0000:20:00.0: Using MSI-X interrupts. 4 rx >queue(s), 4 tx queue(s) >Apr 1 14:06:09 kernel: igb 0000:20:00.1: PCI INT B -> GSI 17 (level, >low) -> IRQ 17 >Apr 1 14:06:09 kernel: igb 0000:20:00.1: Intel(R) Gigabit Ethernet >Network Connection >Apr 1 14:06:09 kernel: igb 0000:20:00.1: eth2: (PCIe:2.5Gb/s:Width x4) >00:1b:21:6e:9c:77 >Apr 1 14:06:09 kernel: igb 0000:20:00.1: eth2: PBA No: e43709-005 >Apr 1 14:06:09 kernel: igb 0000:20:00.1: Using MSI-X interrupts. 4 rx >queue(s), 4 tx queue(s) >Apr 1 14:06:09 kernel: igb: eth1 NIC Link is Up 1000 Mbps Full Duplex, >Flow Control: RX > >Link detection after reconnect: >Apr 1 14:07:20 kernel: igb: eth1 NIC Link is Down >Apr 1 14:07:24 kernel: igb: eth1 NIC Link is Up 1000 Mbps Full Duplex, >Flow Control: RX > >I don't seem to be able to reproduce the issue with another switch, >tried over 15+ reboots. I've double checked the switch itself is fine >by only connecting two systems to it and also tested different ports. >Using a e1000e based card instead of igb seems fine, too. Though this >might >all be unrelated as I takes some boots until the issue appears again. > >A co-worker reported a similar sounding issue earlier, >except that this time it's without virtualization: >http://www.mail-archive.com/e1000- >[email protected]/msg02720.html > >Any idea what could be going on? > >I'll retry with kernel 2.6.39rc-1 in the meantime. > >Thanks in advance, >Thomas Jarosch > >------------------------------------------------------------------------ >------ >Create and publish websites with WebMatrix >Use the most popular FREE web apps or write code yourself; >WebMatrix provides all the features you need to develop and >publish your website. http://p.sf.net/sfu/ms-webmatrix-sf >_______________________________________________ >E1000-devel mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/e1000-devel >To learn more about Intel® Ethernet, visit >http://communities.intel.com/community/wired
Hello, That's an interesting sounding issue. You said that you couldn't reproduce it with another switch. What kind of switch are you using? When trying another one, was it a different one in make/model or just a different one of the same make/model. When you unplug and plug the cable back the adapter is reset and reconfigured to defaults, although it should be that way after a reboot as well and it shouldn't be different from one reboot to the other unless some other interaction with the os is the problem. Some other information that would be helpful: output of lspci -vvv and also lspci -tvvv, both when the problem is occurring and when it is not. Can you download ethregs from SourceForge or update your ethtool to the latest and give me a register dump both before and during the problem. If you open an issue with Source Forge, it gives us a place to post data and track info. Thanks, Carolyn Carolyn Wyborny Linux Development LAN Access Division Intel Corporation ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
