[yocto] [meta-raspberrypi] Network not working after first boot success

[Rich Bayliss]

On 18 July 2013 14:50, Rich Bayliss <richbayliss at gmail.com> wrote:
> On 18 July 2013 12:28, Rich Bayliss <richbayliss at gmail.com> wrote:
>> On 18 July 2013 12:07, Paul Barker <paul at paulbarker.me.uk> wrote:
>>> On 18 July 2013 11:55, Rich Bayliss <richbayliss at gmail.com> wrote:
>>>>>>
>>>>>> Is this a known issue? Does anyone have any ideas?
>>>>>>
>>>
>>> Could you try running 'ip addr' and 'ip link' instead of 'ifconfig'?
>>> Just wondering whether they query information differently and might
>>> show something else. The other place to look is in the output of
>>> 'dmesg'.
>>>
>>> Does un-plugging and re-plugging the network cable (without running
>>> 'ifup' or 'ifdown') make any difference?
>>>
>>> --
>>> Paul Barker
>>>
>>> Email: paul at paulbarker.me.uk
>>> http://www.paulbarker.me.uk
>>
>> I have tried unplugging/replugging and it stays down.
>>
>> I have run the commands and there is a difference, however I also ran
>> "lsmod" and there is a big difference.
>>
>> Working:
>> root at raspberrypi:~# lsmod
>>     Not tainted
>> ipv6 281069 12 - Live 0xbf02c000
>> spidev 5343 0 - Live 0xbf022000
>> joydev 9477 0 - Live 0xbf01c000
>> evdev 9486 0 - Live 0xbf015000
>> leds_gpio 2194 0 - Live 0xbf011000
>> led_class 3581 1 leds_gpio, Live 0xbf00d000
>> spi_bcm2708 4631 0 - Live 0xbf004000
>> i2c_bcm2708 3879 0 - Live 0xbf000000
>>
>> Not working:
>> root at raspberrypi:~# lsmod
>>     Not tainted
>> ipv6 281069 12 - Live 0xbf00d000
>> joydev 9477 0 - Live 0xbf007000
>> evdev 9486 0 - Live 0xbf000000
>>
>> At this point, if I then do the "ifdown"/"ifup" dance, my connection
>> works, but not more modules are loaded - does this help you guys?
>>
>> --
>> Rich Bayliss
>
> I have connected a serial terminal now, and I can provide boot logs.
> It looks like maybe UDEV is causing/part of the issue. When it boots
> successfully, then I dont get a "udevadm settle" message:
>
> Starting udev
> [    3.085091] smsc95xx v1.0.4
> [    3.157196] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at
> usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:e1:f6:e2
> [    3.487588] udevd[74]: starting version 182
> Starting Bootlog daemon: bootlogd.
> [    6.162643] EXT4-fs (mmcblk0p2): re-mounted. Opts:
> errors=remount-ro,data=ordered
> Configuring network interfaces... udhcpc (v1.21.1) started
> Sending discover...
> [    9.138863] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps,
> full-duplex, lpa 0xC1E1
> Sending discover...
> Sending select for 192.168.1.110...
> Lease of 192.168.1.110 obtained, lease time 268435455
> /etc/udhcpc.d/50default: Adding DNS 192.168.1.254
> done.
>
> However when the network is broken I see the following:
>
> Starting udev
> [    5.342406] udevd[74]: starting version 182
> Starting Bootlog daemon: bootlogd.
> [    7.938281] EXT4-fs (mmcblk0p2): re-mounted. Opts:
> errors=remount-ro,data=ordered
>
> udevadm settle - timeout of 3 seconds reached, the event queue contains:
>   /sys/devices/platform/bcm2708_usb/usb1/1-1/1-1.1/1-1.1:1.0/net/eth0 (980)
>   /sys/devices/platform/mmc_host/mmc0/mmc0:8fe4/block/mmcblk0/mmcblk0p1 (985)
>   /sys/devices/platform/mmc_host/mmc0/mmc0:8fe4/block/mmcblk0/mmcblk0p2 (986)
> Configuring network interfaces... ifup: interface lo already configured
> ifup: interface eth0 already configured
> done.
>
> --
> Rich Bayliss

Could be a total wildcard, but I have managed to reliably reproduce
this behavior:

1) Boot from fresh SD image - network working.
2) run "dmesg | grep recovery" - no results
3) pull the power
4) Boots without network
5) run "dmesg | grep recovery" - 1 result "EXT4-fs (mmcblk0p2):
recovery complete"
6) run "reboot"
7) Boots with network
8) run "dmesg | grep recovery" - no results

I wonder if the dirty reboot by power pull as making the boot process
longer, and thus UDEV is failing to bring eth0 up in time? What do you
guys think?

--
Rich Bayliss