* Re: [meta-raspberrypi] Network not working after first boot success [not found] <CAHLvMfaELf9WAjgZJ_wLqGr1wv-wZK++5S27XYbs5ffu668ZRw@mail.gmail.com> @ 2013-07-17 20:12 ` Rich Bayliss 2013-07-18 8:01 ` Andrei Gherzan 0 siblings, 1 reply; 15+ messages in thread From: Rich Bayliss @ 2013-07-17 20:12 UTC (permalink / raw) To: yocto I am building rpi-basic-image and I get a successful build and first-run. My Pi gets an address over DHCP and I can login over SSH. However, if I pull the power/reboot - then on the next start-up my network stays down. On the local console, if I issue "ifup eth0" I am told the interface is already up, while "ifconfig" show no interfaces, not even "lo". If I do and "ifdown eth0" followed by an "ifup eth0" then my DHCP kicks in and everything is back to normal... until the next reboot. Is this a known issue? Does anyone have any ideas? -- Rich Bayliss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [meta-raspberrypi] Network not working after first boot success 2013-07-17 20:12 ` [meta-raspberrypi] Network not working after first boot success Rich Bayliss @ 2013-07-18 8:01 ` Andrei Gherzan 2013-07-18 10:55 ` Rich Bayliss 0 siblings, 1 reply; 15+ messages in thread From: Andrei Gherzan @ 2013-07-18 8:01 UTC (permalink / raw) To: Rich Bayliss; +Cc: Yocto Project [-- Attachment #1: Type: text/plain, Size: 742 bytes --] On Wed, Jul 17, 2013 at 11:12 PM, Rich Bayliss <richbayliss@gmail.com>wrote: > I am building rpi-basic-image and I get a successful build and > first-run. My Pi gets an address over DHCP and I can login over SSH. > > However, if I pull the power/reboot - then on the next start-up my > network stays down. On the local console, if I issue "ifup eth0" I am > told the interface is already up, while "ifconfig" show no interfaces, > not even "lo". If I do and "ifdown eth0" followed by an "ifup eth0" > then my DHCP kicks in and everything is back to normal... until the > next reboot. > > Is this a known issue? Does anyone have any ideas? > > > Never seen this but will try to reproduce it. Will provide feedback. Andrei [-- Attachment #2: Type: text/html, Size: 1249 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [meta-raspberrypi] Network not working after first boot success 2013-07-18 8:01 ` Andrei Gherzan @ 2013-07-18 10:55 ` Rich Bayliss 2013-07-18 11:07 ` Paul Barker 0 siblings, 1 reply; 15+ messages in thread From: Rich Bayliss @ 2013-07-18 10:55 UTC (permalink / raw) To: Andrei Gherzan; +Cc: Yocto Project On 18 July 2013 09:01, Andrei Gherzan <andrei@gherzan.ro> wrote: > > > > On Wed, Jul 17, 2013 at 11:12 PM, Rich Bayliss <richbayliss@gmail.com> > wrote: >> >> I am building rpi-basic-image and I get a successful build and >> first-run. My Pi gets an address over DHCP and I can login over SSH. >> >> However, if I pull the power/reboot - then on the next start-up my >> network stays down. On the local console, if I issue "ifup eth0" I am >> told the interface is already up, while "ifconfig" show no interfaces, >> not even "lo". If I do and "ifdown eth0" followed by an "ifup eth0" >> then my DHCP kicks in and everything is back to normal... until the >> next reboot. >> >> Is this a known issue? Does anyone have any ideas? >> >> > Never seen this but will try to reproduce it. > Will provide feedback. > > Andrei Thanks Andrei, I would appreciate that. For reference, I have downloaded the latest Raspbian image and I have no such issue - so I would consider this as ruling out a hardware issue. Also, I have noticed the Ethernet activity LEDs go off and on, during boot, when the interface is started correctly. When I have the issue, they come on initially but never go off/on again. Maybe an initialization error? -- Rich Bayliss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [meta-raspberrypi] Network not working after first boot success 2013-07-18 10:55 ` Rich Bayliss @ 2013-07-18 11:07 ` Paul Barker 2013-07-18 11:28 ` Rich Bayliss 0 siblings, 1 reply; 15+ messages in thread From: Paul Barker @ 2013-07-18 11:07 UTC (permalink / raw) To: Rich Bayliss; +Cc: Yocto Project On 18 July 2013 11:55, Rich Bayliss <richbayliss@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@paulbarker.me.uk http://www.paulbarker.me.uk ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [meta-raspberrypi] Network not working after first boot success 2013-07-18 11:07 ` Paul Barker @ 2013-07-18 11:28 ` Rich Bayliss 2013-07-18 13:50 ` Rich Bayliss 0 siblings, 1 reply; 15+ messages in thread From: Rich Bayliss @ 2013-07-18 11:28 UTC (permalink / raw) To: Paul Barker; +Cc: Yocto Project On 18 July 2013 12:07, Paul Barker <paul@paulbarker.me.uk> wrote: > On 18 July 2013 11:55, Rich Bayliss <richbayliss@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@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@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@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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [meta-raspberrypi] Network not working after first boot success 2013-07-18 11:28 ` Rich Bayliss @ 2013-07-18 13:50 ` Rich Bayliss 2013-07-18 14:07 ` Rich Bayliss 2013-07-18 14:10 ` Gary Thomas 0 siblings, 2 replies; 15+ messages in thread From: Rich Bayliss @ 2013-07-18 13:50 UTC (permalink / raw) To: Paul Barker; +Cc: Yocto Project On 18 July 2013 12:28, Rich Bayliss <richbayliss@gmail.com> wrote: > On 18 July 2013 12:07, Paul Barker <paul@paulbarker.me.uk> wrote: >> On 18 July 2013 11:55, Rich Bayliss <richbayliss@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@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@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@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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [meta-raspberrypi] Network not working after first boot success 2013-07-18 13:50 ` Rich Bayliss @ 2013-07-18 14:07 ` Rich Bayliss 2013-07-18 14:13 ` Gary Thomas 2013-07-18 22:27 ` Eric Bénard 2013-07-18 14:10 ` Gary Thomas 1 sibling, 2 replies; 15+ messages in thread From: Rich Bayliss @ 2013-07-18 14:07 UTC (permalink / raw) To: Paul Barker; +Cc: Yocto Project On 18 July 2013 14:50, Rich Bayliss <richbayliss@gmail.com> wrote: > On 18 July 2013 12:28, Rich Bayliss <richbayliss@gmail.com> wrote: >> On 18 July 2013 12:07, Paul Barker <paul@paulbarker.me.uk> wrote: >>> On 18 July 2013 11:55, Rich Bayliss <richbayliss@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@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@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@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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [meta-raspberrypi] Network not working after first boot success 2013-07-18 14:07 ` Rich Bayliss @ 2013-07-18 14:13 ` Gary Thomas 2013-07-18 14:20 ` Rich Bayliss 2013-07-18 22:27 ` Eric Bénard 1 sibling, 1 reply; 15+ messages in thread From: Gary Thomas @ 2013-07-18 14:13 UTC (permalink / raw) To: yocto On 2013-07-18 08:07, Rich Bayliss wrote: > On 18 July 2013 14:50, Rich Bayliss <richbayliss@gmail.com> wrote: >> On 18 July 2013 12:28, Rich Bayliss <richbayliss@gmail.com> wrote: >>> On 18 July 2013 12:07, Paul Barker <paul@paulbarker.me.uk> wrote: >>>> On 18 July 2013 11:55, Rich Bayliss <richbayliss@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@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@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@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 ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [meta-raspberrypi] Network not working after first boot success 2013-07-18 14:13 ` Gary Thomas @ 2013-07-18 14:20 ` Rich Bayliss 2013-07-18 14:38 ` Gary Thomas 0 siblings, 1 reply; 15+ messages in thread From: Rich Bayliss @ 2013-07-18 14:20 UTC (permalink / raw) To: Gary Thomas; +Cc: Yocto Project Indeed. However the usage requirement of the system rely on being headless, and thus a power-pull is likely to happen. I guess the only way to rule this in/out would be run with a RO rootfs - and mount a sperate partition for user files. Do you know how I can achieve this? On 18 July 2013 15:13, Gary Thomas <gary@mlbassoc.com> wrote: > On 2013-07-18 08:07, Rich Bayliss wrote: >> >> On 18 July 2013 14:50, Rich Bayliss <richbayliss@gmail.com> wrote: >>> >>> On 18 July 2013 12:28, Rich Bayliss <richbayliss@gmail.com> wrote: >>>> >>>> On 18 July 2013 12:07, Paul Barker <paul@paulbarker.me.uk> wrote: >>>>> >>>>> On 18 July 2013 11:55, Rich Bayliss <richbayliss@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@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@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@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 > ------------------------------------------------------------ > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- Rich Bayliss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [meta-raspberrypi] Network not working after first boot success 2013-07-18 14:20 ` Rich Bayliss @ 2013-07-18 14:38 ` Gary Thomas 2013-07-18 14:41 ` Rich Bayliss 0 siblings, 1 reply; 15+ messages in thread From: Gary Thomas @ 2013-07-18 14:38 UTC (permalink / raw) To: Rich Bayliss; +Cc: Yocto Project On 2013-07-18 08:20, Rich Bayliss wrote: > Indeed. However the usage requirement of the system rely on being > headless, and thus a power-pull is likely to happen. > > I guess the only way to rule this in/out would be run with a RO rootfs > - and mount a sperate partition for user files. Do you know how I can > achieve this? There is some support in recent OE-core for read-only rootfs. Search the Yocto project archives for more information (I've not tried it yet). The more interesting thing is that I have systems other than the RPI that are built using Poky/Yocto where the power is often the cause of a reboot and I've never seen this error/situation occur! Maybe I can experiment a bit and compare the RPI build with my other systems (I have both) and see why. Not sure when I can get to it though... > > On 18 July 2013 15:13, Gary Thomas <gary@mlbassoc.com> wrote: >> On 2013-07-18 08:07, Rich Bayliss wrote: >>> >>> On 18 July 2013 14:50, Rich Bayliss <richbayliss@gmail.com> wrote: >>>> >>>> On 18 July 2013 12:28, Rich Bayliss <richbayliss@gmail.com> wrote: >>>>> >>>>> On 18 July 2013 12:07, Paul Barker <paul@paulbarker.me.uk> wrote: >>>>>> >>>>>> On 18 July 2013 11:55, Rich Bayliss <richbayliss@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@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@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@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 >> ------------------------------------------------------------ >> _______________________________________________ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > > > -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [meta-raspberrypi] Network not working after first boot success 2013-07-18 14:38 ` Gary Thomas @ 2013-07-18 14:41 ` Rich Bayliss 2013-07-18 21:49 ` Andrei Gherzan 0 siblings, 1 reply; 15+ messages in thread From: Rich Bayliss @ 2013-07-18 14:41 UTC (permalink / raw) To: Gary Thomas; +Cc: Yocto Project On 18 July 2013 15:38, Gary Thomas <gary@mlbassoc.com> wrote: > On 2013-07-18 08:20, Rich Bayliss wrote: >> >> Indeed. However the usage requirement of the system rely on being >> headless, and thus a power-pull is likely to happen. >> >> I guess the only way to rule this in/out would be run with a RO rootfs >> - and mount a sperate partition for user files. Do you know how I can >> achieve this? > > > There is some support in recent OE-core for read-only rootfs. Search > the Yocto project archives for more information (I've not tried it yet). > > The more interesting thing is that I have systems other than the RPI > that are built using Poky/Yocto where the power is often the cause > of a reboot and I've never seen this error/situation occur! Maybe > I can experiment a bit and compare the RPI build with my other systems > (I have both) and see why. Not sure when I can get to it though... > ------------------------------------------------------------ > Gary Thomas | Consulting for the > MLB Associates | Embedded world > ------------------------------------------------------------ OK Gary, thanks. I have found an article which states including "read-only-rootfs" in the IMAGE_FEATURES will provide me with just that. I am building now, so let's see what happens. In my opinion, although a power-failure reboot is undesirable from the OS perspective, I would expect it to come back with networking up - or at least auto-magically reboot if they aren't for some reason. -- Rich Bayliss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [meta-raspberrypi] Network not working after first boot success 2013-07-18 14:41 ` Rich Bayliss @ 2013-07-18 21:49 ` Andrei Gherzan 0 siblings, 0 replies; 15+ messages in thread From: Andrei Gherzan @ 2013-07-18 21:49 UTC (permalink / raw) To: Rich Bayliss; +Cc: Yocto Project [-- Attachment #1: Type: text/plain, Size: 1982 bytes --] On Jul 18, 2013 5:42 PM, "Rich Bayliss" <richbayliss@gmail.com> wrote: > > On 18 July 2013 15:38, Gary Thomas <gary@mlbassoc.com> wrote: > > On 2013-07-18 08:20, Rich Bayliss wrote: > >> > >> Indeed. However the usage requirement of the system rely on being > >> headless, and thus a power-pull is likely to happen. > >> > >> I guess the only way to rule this in/out would be run with a RO rootfs > >> - and mount a sperate partition for user files. Do you know how I can > >> achieve this? > > > > > > There is some support in recent OE-core for read-only rootfs. Search > > the Yocto project archives for more information (I've not tried it yet). > > > > The more interesting thing is that I have systems other than the RPI > > that are built using Poky/Yocto where the power is often the cause > > of a reboot and I've never seen this error/situation occur! Maybe > > I can experiment a bit and compare the RPI build with my other systems > > (I have both) and see why. Not sure when I can get to it though... > > ------------------------------------------------------------ > > Gary Thomas | Consulting for the > > MLB Associates | Embedded world > > ------------------------------------------------------------ > > OK Gary, thanks. I have found an article which states including > "read-only-rootfs" in the IMAGE_FEATURES will provide me with just > that. I am building now, so let's see what happens. > > In my opinion, although a power-failure reboot is undesirable from the > OS perspective, I would expect it to come back with networking up - or > at least auto-magically reboot if they aren't for some reason. I agree. It should be running correctly. And if it doesn't we need to fix this. Power fails happen. So this is no excuse. Well, it seems that I can't replicate this. Have network all the time. 4 reboots. Will retry tomorrow. Don't know what build I have. Will recompile master. ag [-- Attachment #2: Type: text/html, Size: 2508 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [meta-raspberrypi] Network not working after first boot success 2013-07-18 14:07 ` Rich Bayliss 2013-07-18 14:13 ` Gary Thomas @ 2013-07-18 22:27 ` Eric Bénard 2013-07-19 8:08 ` Rich Bayliss 1 sibling, 1 reply; 15+ messages in thread From: Eric Bénard @ 2013-07-18 22:27 UTC (permalink / raw) To: Rich Bayliss; +Cc: Yocto Project Hi Rich, Le Thu, 18 Jul 2013 15:07:01 +0100, Rich Bayliss <richbayliss@gmail.com> a écrit : > On 18 July 2013 14:50, Rich Bayliss <richbayliss@gmail.com> wrote: > > Configuring network interfaces... ifup: interface lo already configured > > ifup: interface eth0 already configured > > done. > > > 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? > this problem occured here when /var/run/network/ifstate is on a RW persistent storage and not in a tmpfs : the interface state can exist when booting after a dirty reboot. A workaround is to hack meta/recipes-core/init-ifupdown/init-ifupdown-1.0/init and add ifdown -a just before ifup -a in the start) section Eric ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [meta-raspberrypi] Network not working after first boot success 2013-07-18 22:27 ` Eric Bénard @ 2013-07-19 8:08 ` Rich Bayliss 0 siblings, 0 replies; 15+ messages in thread From: Rich Bayliss @ 2013-07-19 8:08 UTC (permalink / raw) To: Eric Bénard; +Cc: Yocto Project On 18 July 2013 23:27, Eric Bénard <eric@eukrea.com> wrote: > this problem occured here when /var/run/network/ifstate is on a RW > persistent storage and not in a tmpfs : the interface state can exist > when booting after a dirty reboot. > > A workaround is to hack > meta/recipes-core/init-ifupdown/init-ifupdown-1.0/init and add > ifdown -a > just before ifup -a in the start) section > > Eric I will try this hack Eric, but I suppose this opens another question - why /var/run is held on a non-TMPFS? I would think (and this is not based on any authority) that since /var/run is mainly for tracking state, that after a reboot of any kind it should remain blank. I have tested deleting /var/run/ifstate and pulling the plug, and it returns on next reboot. I think this might be the EXT4 recovery kicking in and putting the file back? -- Rich Bayliss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [meta-raspberrypi] Network not working after first boot success 2013-07-18 13:50 ` Rich Bayliss 2013-07-18 14:07 ` Rich Bayliss @ 2013-07-18 14:10 ` Gary Thomas 1 sibling, 0 replies; 15+ messages in thread From: Gary Thomas @ 2013-07-18 14:10 UTC (permalink / raw) To: yocto On 2013-07-18 07:50, Rich Bayliss wrote: > On 18 July 2013 12:28, Rich Bayliss <richbayliss@gmail.com> wrote: >> On 18 July 2013 12:07, Paul Barker <paul@paulbarker.me.uk> wrote: >>> On 18 July 2013 11:55, Rich Bayliss <richbayliss@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@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@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@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. > This looks more like there is some state information left around that is keeping the network from coming up - it thinks that it already is up. In your original post, you mentioned 'I pull the power/reboot'. Is that how you are rebooting the board, by just yanking the power? If so, that could definitely explain such a case where state information says one thing and real life doesn't match. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2013-07-19 8:08 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAHLvMfaELf9WAjgZJ_wLqGr1wv-wZK++5S27XYbs5ffu668ZRw@mail.gmail.com> 2013-07-17 20:12 ` [meta-raspberrypi] Network not working after first boot success Rich Bayliss 2013-07-18 8:01 ` Andrei Gherzan 2013-07-18 10:55 ` Rich Bayliss 2013-07-18 11:07 ` Paul Barker 2013-07-18 11:28 ` Rich Bayliss 2013-07-18 13:50 ` Rich Bayliss 2013-07-18 14:07 ` Rich Bayliss 2013-07-18 14:13 ` Gary Thomas 2013-07-18 14:20 ` Rich Bayliss 2013-07-18 14:38 ` Gary Thomas 2013-07-18 14:41 ` Rich Bayliss 2013-07-18 21:49 ` Andrei Gherzan 2013-07-18 22:27 ` Eric Bénard 2013-07-19 8:08 ` Rich Bayliss 2013-07-18 14:10 ` Gary Thomas
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.