e1000: more than two seconds to get the flag RUNNING
Subsystems (2)
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:1Thu 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
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.
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.
Cheers,
John
Quoted 70 lines
-----Original Message-----
From: Nicolas Dichtel [mailto:[email protected]]
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 RUNNINGHi,
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/bashsleep_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
doneshelby:~# 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:1Thu 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 readyThu Dec 16 12:45:58 EST 2010
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1shelby:~#
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
Quoted 1 line · John
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.
Quoted 2 lines
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
Quoted 75 lines
Cheers,
JohnQuoted 70 lines
-----Original Message-----
From: Nicolas Dichtel [mailto:[email protected]]
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 RUNNINGHi,
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/bashsleep_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
doneshelby:~# 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:1Thu 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 readyThu Dec 16 12:45:58 EST 2010
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1shelby:~#
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
Signature · 22 lines
Nicolas DICHTEL 6WIND R&D Engineer Tel: +33 1 39 30 92 10 Fax: +33 1 39 30 92 11 [email protected] 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.