From: Nicolas D. <nic...@6w...> - 2010-12-20 09:46:44
|
Le 17.12.2010 18:17, Ronciak, John a écrit : > Removed netdev and moved this to e1000-devel and a few people not associated with the e1000 driver. > > So when did you start to see a change in the link speed? Did something change like the kernel or driver version? Was this NIC moved to the system that is showing this problem? Does using the latest e1000 driver from our Sourceforge site (e1000.sf.net) show any difference? I think that this issue is here since a long time (I reproduce it with a linux 2.6.15, driver version: 6.1.16), but I notice it recently. One of our daemons, that check the link (through the flag IFF_RUNNING), take time to get it. Note that it is only this sequence (we start with the interface up) "up, down, up" (without any delay) that causes the bug. If we just do "down, up", link is got immediatly. I reproduce it with the last driver (8.0.25). Note that I won't be able to compile it with a recent linux due to this commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b738127dfb469bb9f595cdace30e7f881e8146b2 (VLAN_GROUP_ARRAY_LEN has been removed), so I simply replace VLAN_GROUP_ARRAY_LEN by VLAN_N_VID. > > As I've said link can take up to 4 seconds to auto-negotiate so unless something has changed to cause this I'm not sure this is a problem. Sure, but as I said, it's only with a particular sequence that we got the delay. Thank you for you help, Nicolas > > Please let us know. > > Thanks. > > Cheers, > John > > >> -----Original Message----- >> From: Nicolas Dichtel [mailto:nic...@6w...] >> Sent: Friday, December 17, 2010 2:44 AM >> To: Ronciak, John >> Cc: Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W; Wyborny, >> Carolyn; Skidmore, Donald C; Rose, Gregory V; Waskiewicz Jr, Peter P; >> Duyck, Alexander H; netdev >> Subject: Re: e1000: more than two seconds to get the flag RUNNING >> >> Le 16.12.2010 17:44, Ronciak, John a écrit : >>> I'm assuming when you say "get the flag RUNNING" you mean to get >> link. Is that right? Are you connected to a switch? It is entirely >> possible to wait 2 seconds to get link on a 1000Base-T (RJ45) link. By >> specification link can take as much as 4 seconds. Do you have spanning >> tree enabled on the switch? That could be delaying link as well. >> Yes, I mean 'get the link'. I was connected to a switch, but no >> spanning tree. >> >>> To check this connect it back to back to another system. With this >> old of an adapter you may need to connect the two systems with a cross- >> over cable. >> I get the same issue. >> >> >> Regards, >> Nicolas >> >>> Cheers, >>> John >>> >>> >>>> -----Original Message----- >>>> From: Nicolas Dichtel [mailto:nic...@6w...] >>>> Sent: Thursday, December 16, 2010 8:17 AM >>>> To: Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W; Wyborny, >>>> Carolyn; Skidmore, Donald C; Rose, Gregory V; Waskiewicz Jr, Peter >> P; >>>> Duyck, Alexander H; Ronciak, John >>>> Cc: netdev >>>> Subject: e1000: more than two seconds to get the flag RUNNING >>>> >>>> Hi, >>>> >>>> maybe this problem has already been discussed, but I didn't find the >>>> thread. >>>> When I put an interface managed by the e1000 driver up, down and up >>>> again, I must wait more than 2 seconds to get the flag running >> again. >>>> Here is the sequence: >>>> >>>> shelby:~# uname -a >>>> Linux shelby 2.6.37-rc5+ #9 SMP Wed Dec 15 13:16:10 EST 2010 i686 >>>> GNU/Linux shelby:~# lsmod | grep e1000 >>>> e1000 76543 0 >>>> shelby:~# lspci | grep Gigabit >>>> 01:09.0 Ethernet controller: Intel Corporation 82540EM Gigabit >>>> Ethernet Controller (rev 02) shelby:~# cat check_link_state.sh >>>> #!/bin/bash >>>> >>>> sleep_time=$1 >>>> ip link set eth0 up >>>> ip link set eth0 down >>>> ip link set eth0 up >>>> while [ $sleep_time -gt 0 ] ; do >>>> date >>>> #ip link show eth0 >>>> ifconfig eth0 | grep MULTICAST >>>> sleep 1 >>>> echo "" >>>> sleep_time=`expr $sleep_time - 1` done shelby:~# ifconfig eth0 >>>> eth0 Link encap:Ethernet HWaddr 00:30:1b:b4:dc:88 >>>> inet addr:10.16.0.72 Bcast:10.16.0.255 >> Mask:255.255.255.0 >>>> inet6 addr: fe80::230:1bff:feb4:dc88/64 Scope:Link >>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >>>> RX packets:22051 errors:0 dropped:0 overruns:0 frame:0 >>>> TX packets:63 errors:0 dropped:0 overruns:0 carrier:0 >>>> collisions:0 txqueuelen:1000 >>>> RX bytes:2480685 (2.3 MiB) TX bytes:5242 (5.1 KiB) >>>> >>>> shelby:~# ./check_link_state.sh 3 >>>> [83270.080175] ADDRCONF(NETDEV_UP): eth0: link is not ready Thu Dec >>>> 16 >>>> 12:45:56 EST 2010 >>>> UP BROADCAST MULTICAST MTU:1500 Metric:1 >>>> >>>> Thu Dec 16 12:45:57 EST 2010 >>>> UP BROADCAST MULTICAST MTU:1500 Metric:1 [83271.828371] >>>> e1000: eth0 NIC Link is Up 100 Mbps Half Duplex, Flow Control: None >>>> [83271.835878] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready >>>> >>>> Thu Dec 16 12:45:58 EST 2010 >>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >>>> >>>> shelby:~# >>>> >>>> I get the same result with a 2.6.15, so it seems that the problem is >>>> here since a long time. >>>> Has anyone an input for this problem? >>>> >>>> >>>> Regards, >>>> Nicolas >> -- >> Nicolas DICHTEL >> 6WIND >> R&D Engineer >> >> Tel: +33 1 39 30 92 10 >> Fax: +33 1 39 30 92 11 >> nic...@6w... >> www.6wind.com >> Join the Multicore Packet Processing Forum: >> www.multicorepacketprocessing.com >> >> Ce courriel ainsi que toutes les pièces jointes, est uniquement destiné >> à son ou ses destinataires. Il contient des informations >> confidentielles qui sont la propriété de 6WIND. Toute révélation, >> distribution ou copie des informations qu'il contient est strictement >> interdite. Si vous avez reçu ce message par erreur, veuillez >> immédiatement le signaler à l'émetteur et détruire toutes les données >> reçues. >> >> This e-mail message, including any attachments, is for the sole use of >> the intended recipient(s) and contains information that is confidential >> and proprietary to 6WIND. All unauthorized review, use, disclosure or >> distribution is prohibited. If you are not the intended recipient, >> please contact the sender by reply e-mail and destroy all copies of the >> original message. > -- Nicolas DICHTEL 6WIND R&D Engineer Tel: +33 1 39 30 92 10 Fax: +33 1 39 30 92 11 nic...@6w... www.6wind.com Join the Multicore Packet Processing Forum: www.multicorepacketprocessing.com Ce courriel ainsi que toutes les pièces jointes, est uniquement destiné à son ou ses destinataires. Il contient des informations confidentielles qui sont la propriété de 6WIND. Toute révélation, distribution ou copie des informations qu'il contient est strictement interdite. Si vous avez reçu ce message par erreur, veuillez immédiatement le signaler à l'émetteur et détruire toutes les données reçues. This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to 6WIND. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. |