Re: [E1000-devel] e1000: more than two seconds to get the flag RUNNING

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

That's not quite the same thing but I don't think it matters.  The issue is that the transition from your up call to down means the PHY is being reset which causes the link to renegotiate and is taking 2 seconds (can take up to 4 seconds) to again be acquired.  So this is expected behavior.  There is a difference between what SW is seeing as link and what the actual PHY is seeing as link especially in very short time periods.

Cheers,
John

> -----Original Message-----
> From: Nicolas Dichtel [mailto:nic...@6w...]
> Sent: Monday, December 20, 2010 10:01 AM
> To: Ronciak, John
> Cc: Kirsher, Jeffrey T; Brandeburg, Jesse; Duyck, Alexander H; 'e1000-
> de...@li...'
> Subject: Re: e1000: more than two seconds to get the flag RUNNING
> 
> Le 20.12.2010 18:02, Ronciak, John a écrit :
> > When you start your "up, down, up" sequence is there link already
> before you start?  I'm thinking that the initial up is restarting auto-
> negotiation which isn't complete when the down is issued which is
> causing thing to once again reset.
> Yes, there is link before the first up.
> 
> >
> > Please do an "ethtool ethx" (ethx being your interface) in between
> each up, down call.  So it would look like:
> > ethtool ethx
> > ifconfig ethx up
> > ethtool ethx
> > ifconfig ethx down
> > ethtool ethx
> > ifconfig ethx up
> > ethtool ethx
> >
> > I want to see where link is at each stage.
> Here is the log:
> 
> shelby:~# ./check_link_state.sh 4
> Settings for eth0:
>          Supported ports: [ TP ]
>          Supported link modes:   10baseT/Half 10baseT/Full
>                                  100baseT/Half 100baseT/Full
>                                  1000baseT/Full
>          Supports auto-negotiation: Yes
>          Advertised link modes:  10baseT/Half 10baseT/Full
>                                  100baseT/Half 100baseT/Full
>                                  1000baseT/Full
>          Advertised auto-negotiation: Yes
>          Speed: 100Mb/s
>          Duplex: Half
>          Port: Twisted Pair
>          PHYAD: 0
>          Transceiver: internal
>          Auto-negotiation: on
>          Supports Wake-on: umbg
>          Wake-on: g
>          Current message level: 0x00000007 (7)
>          Link detected: yes
> Settings for eth0:
>          Supported ports: [ TP ]
>          Supported link modes:   10baseT/Half 10baseT/Full
>                                  100baseT/Half 100baseT/Full
>                                  1000baseT/Full
>          Supports auto-negotiation: Yes
>          Advertised link modes:  10baseT/Half 10baseT/Full
> [   83.725469] ADDRCONF(NETDEV_UP): eth0: link is not ready
> 
>                                  1000baseT/Full
>          Advertised auto-negotiation: Yes
>          Speed: 100Mb/s
>          Duplex: Half
>          Port: Twisted Pair
>          PHYAD: 0
>          Transceiver: internal
>          Auto-negotiation: on
>          Supports Wake-on: umbg
>          Wake-on: g
>          Current message level: 0x00000007 (7)
>          Link detected: yes
> Settings for eth0:
>          Supported ports: [ TP ]
>          Supported link modes:   10baseT/Half 10baseT/Full
>                                  100baseT/Half 100baseT/Full
>                                  1000baseT/Full
>          Supports auto-negotiation: Yes
>          Advertised link modes:  10baseT/Half 10baseT/Full
>                                  100baseT/Half 100baseT/Full
>                                  1000baseT/Full
>          Advertised auto-negotiation: Yes
>          Speed: Unknown! (65535)
>          Duplex: Unknown! (255)
>          Port: Twisted Pair
>          PHYAD: 0
>          Transceiver: internal
>          Auto-negotiation: on
>          Supports Wake-on: umbg
>          Wake-on: g
>          Current message level: 0x00000007 (7)
>          Link detected: no
> Settings for eth0:
>          Supported ports: [ TP ]
>          Supported link modes:   10baseT/Half 10baseT/Full
>                                  100baseT/Half 100baseT/Full
>                                  1000baseT/Full
>          Supports auto-negotiation: Yes
>          Advertised link modes:  10baseT/Half 10baseT/Full
>                                  100baseT/Half 100baseT/Full
>                                  1000baseT/Full
>          Advertised auto-negotiation: Yes
>          Speed: Unknown! (65535)
>          Duplex: Unknown! (255)
>          Port: Twisted Pair
>          PHYAD: 0
>          Transceiver: internal
>          Auto-negotiation: on
>          Supports Wake-on: umbg
>          Wake-on: g
>          Current message level: 0x00000007 (7)
>          Link detected: no
> Mon Dec 20 14:35:02 EST 2010
>            UP BROADCAST MULTICAST  MTU:1500  Metric:1
> 
> Mon Dec 20 14:35:03 EST 2010
>            UP BROADCAST MULTICAST  MTU:1500  Metric:1
> [   85.436369] e1000: eth0 NIC Link is Up 100 Mbps Half Duplex, Flow
> Control: None
> [   85.444012] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> 
> Mon Dec 20 14:35:04 EST 2010
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> 
> Mon Dec 20 14:35:05 EST 2010
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> 
> shelby:~#
> 
> 
> Regards,
> Nicolas
> 
> >
> > Cheers,
> > John
> >
> >
> >> -----Original Message-----
> >> From: Nicolas Dichtel [mailto:nic...@6w...]
> >> Sent: Monday, December 20, 2010 1:20 AM
> >> To: Ronciak, John
> >> Cc: Kirsher, Jeffrey T; Brandeburg, Jesse; Duyck, Alexander H;
> >> 'e1000- de...@li...'
> >> Subject: Re: e1000: more than two seconds to get the flag RUNNING
> >>
> >> 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

Re: [E1000-devel] e1000: more than two seconds to get the flag RUNNING

Intel Ethernet Drivers

Re: [E1000-devel] e1000: more than two seconds to get the flag RUNNING