[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DDC57477F5D6F845A0DDCB99D3C4812D0D2E664702@orsmsx510.amr.corp.intel.com>
Date: Thu, 16 Dec 2010 08:44:42 -0800
From: "Ronciak, John" <john.ronciak@...el.com>
To: "nicolas.dichtel@...nd.com" <nicolas.dichtel@...nd.com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
"Allan, Bruce W" <bruce.w.allan@...el.com>,
"Wyborny, Carolyn" <carolyn.wyborny@...el.com>,
"Skidmore, Donald C" <donald.c.skidmore@...el.com>,
"Rose, Gregory V" <gregory.v.rose@...el.com>,
"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
"Duyck, Alexander H" <alexander.h.duyck@...el.com>
CC: netdev <netdev@...r.kernel.org>
Subject: RE: e1000: more than two seconds to get the flag RUNNING
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
> -----Original Message-----
> From: Nicolas Dichtel [mailto:nicolas.dichtel@...nd.com]
> 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
Powered by blists - more mailing lists