On 20/03/14 15:56, Robert Nelson wrote:

> bootup (wicd seems to take a good 5-15 seconds to get a valid ip
> address over dhcp, conman is slightly faster).
> 
> You can see the ethernet driver taking it's sweet time over dmesg:
> 
> [   29.139188] net eth0: initializing cpsw version 1.12 (0)
> [   29.142439] net eth0: phy found : id is : 0x7c0f1
> [   29.142650] libphy: PHY 4a101000.mdio:01 not found
> [   29.147705] net eth0: phy 4a101000.mdio:01 not found on slave 1
> [   29.164068] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [   32.222827] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
> [   32.222962] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [   34.697540] net eth0: initializing cpsw version 1.12 (0)
> [   34.699719] net eth0: phy found : id is : 0x7c0f1
> [   34.699817] libphy: PHY 4a101000.mdio:01 not found
> [   34.705082] net eth0: phy 4a101000.mdio:01 not found on slave 1
> [   34.715656] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [   35.108521] net eth0: initializing cpsw version 1.12 (0)
> [   35.110713] net eth0: phy found : id is : 0x7c0f1
> [   35.110812] libphy: PHY 4a101000.mdio:01 not found
> [   35.116039] net eth0: phy 4a101000.mdio:01 not found on slave 1
> [   35.126630] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [   37.102955] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
> [   37.103082] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> 
> However, if we enable it in [/etc/network/interfaces], the serial
> login prompt will not show up till after eth0 gets a valid ip or the 2
> minute dhcp time out.  So boot times fall from the 12-15 seconds to
> 30ish.

Something is wrong there, it appears that something is bringing the 
link up/down three times. 
I think three seconds to get link is a bit long, but I see the same. It's 
doing it three times that's costing all the extra time.

Any possibility of dodgy cable or hardware somewhere ?

Regardless, DHCP shouldn't block serial console, it should immediately 
daemonize and let startup move on. If it doesn't then that's a bug.

FWIW I see a single cycle of what's in your dmesg like this:

[    5.480948] net eth0: initializing cpsw version 1.12 (0)
[    5.557625] net eth0: phy found : id is : 0x7c0f1
[    5.557707] libphy: PHY 4a101000.mdio:01 not found
[    5.557716] net eth0: phy 4a101000.mdio:01 not found on slave 1
[    5.564342] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    8.637383] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[    8.637428] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

In context it looks like

13:47:40.543 kernel: [    4.948036] NET: Registered protocol family 10
13:47:40.543 kernel: [    5.024912] EXT4-fs (mmcblk0p2): re-mounted. Opts: 
(null)
13:47:40+00: dhcpcd[131]: version 6.1.0 starting
13:47:40.557 kernel: [    5.480948] net eth0: initializing cpsw version 1.12 (0)
13:47:40+00: dhcpcd[131]: forked to background, child pid 135
13:47:40.638 kernel: [    5.557625] net eth0: phy found : id is : 0x7c0f1
13:47:40.638 kernel: [    5.564342] IPv6: ADDRCONF(NETDEV_UP): eth0: link is 
not ready
13:47:40+00: dhcpcd[135]: eth0: waiting for carrier
13:47:40+00: dhcpcd[135]: eth0: carrier acquired
13:47:40+00: dhcpcd[135]: eth0: carrier lost
13:47:40+00: dhcpcd[135]: eth0: waiting for carrier
13:47:40+00: ntpd[143]: ntpd [email protected] Fri Jan  3 16:05:29 UTC 2014 (1)
13:47:40+00: ntpd[156]: proto: precision = 1.000 usec
13:47:40+00: ntpd[156]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
13:47:40+00: ntpd[156]: Listen normally on 2 lo 127.0.0.1 UDP 123
13:47:40+00: ntpd[156]: peers refreshed
13:47:40+00: ntpd[156]: Listening on routing socket on fd #20 for interface 
updates
13:47:41+00: sshd[157]: Server listening on 0.0.0.0 port 22.
13:47:41+00: sshd[157]: Server listening on :: port 22.
13:47:43+00: dhcpcd[135]: eth0: carrier acquired
13:47:43.717 kernel: [    8.637383] libphy: 4a101000.mdio:00 - Link is Up - 
100/Full
13:47:43.717 kernel: [    8.637428] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link 
becomes ready
13:47:43+00: dhcpcd[135]: eth0: rebinding lease of 172.20.0.21
13:47:43+00: dhcpcd[135]: eth0: leased 172.20.0.21 for 86400 seconds
13:47:43+00: dhcpcd[135]: eth0: adding host route to 172.20.0.21 via 127.0.0.1
13:47:43+00: dhcpcd[135]: eth0: adding route to 172.20.0.0/16
13:47:43+00: dhcpcd[135]: eth0: adding default route via 172.20.255.1
13:47:44+00: ntpd[156]: Listen normally on 4 eth0 172.20.0.21 UDP 123
13:47:44+00: ntpd[156]: peers refreshed

and dhcp gets a lease pretty much immediately the link comes up

So if it's not a cable or hardware problem causing your link to flap three 
times then 
it's a software problem, but that could be in the distro network scripts, wicd 
or 
the kernel. Kernel driver seems stable for a while now, so I'd think one of the 
other 
two is more likely.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to