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

[Gary Thomas]

On 2013-07-18 08:07, Rich Bayliss wrote:
> 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?

I think the key difference is that when you type 'reboot' everything
is shut down sanely and the "saved state" indicates as such.  When you
simply yank the power, the state information is stale and incorrect,
causing your problems.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------