Re: next/master boot: 177 boots: 1 failed, 176 passed (next-20180808)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tony Lindgren <tony@xxxxxxxxxxx> writes:

> Hi,
>
> * Kevin Hilman <khilman@xxxxxxxxxxxx> [180817 15:47]:
>> Hmm, I think I spoke to soon, and now I don't think it's the MMC card.
>> 
>> I'm still seeing periodic failures on this board soon after the MMC
>> init, but only in mainline and next:
>> https://kernelci.org/boot/omap3-beagle-xm
>> 
>> Also, looking at that URL, you'll see that the failures are only for
>> multi_v7 but not omap2plus_defconfig.
>
> I was finally able to reproduce this here this morning with v4.18
> after about 20 boot attempts. Looks like the system boots up, it
> just has a long pause. See the timestamps below where there
> is about 185 second pause:
>
> [    2.307800] mmc0: host does not support reading read-only switch, assuming write-enable
> [    2.318237] mmc0: new high speed SDHC card at address 59b4
> [    2.325592] mmcblk0: mmc0:59b4 SD    14.7 GiB
> [    2.333221]  mmcblk0: p1 p2
> [    2.384490] ehci-omap 48064800.ehci: EHCI Host Controller
> [    2.390045] ehci-omap 48064800.ehci: new USB bus registered, assigned bus number 2
> [    2.399261] ehci-omap 48064800.ehci: irq 93, io mem 0x48064800
> [    2.434387] ehci-omap 48064800.ehci: USB 2.0 started, EHCI 1.00
> [    2.441436] hub 2-0:1.0: USB hub found
> [    2.445404] hub 2-0:1.0: 3 ports detected
> [    2.451751] input: gpio_keys as /devices/platform/gpio_keys/input/input0
> [    2.460144] twl_rtc 48070000.i2c:twl@48:rtc: setting system clock to 2000-01-01 00:05:24
> UTC (946685124)
> [    2.814422] usb 2-2: new high-speed USB device number 2 using ehci-omap
> [    3.016632] hub 2-2:1.0: USB hub found
> [    3.020751] hub 2-2:1.0: 5 ports detected
> [    3.344421] usb 2-2.1: new high-speed USB device number 3 using ehci-omap
> [    3.498474] smsc95xx v1.0.6
> [    3.595184] smsc95xx 2-2.1:1.0 eth0: register 'smsc95xx' at usb-48064800.ehci-2.1, smsc95
> xx USB 2.0 Ethernet, 11:22:33:44:55:66
> [  188.843536] random: crng init done
> [  188.951354] smsc95xx 2-2.1:1.0 eth0: hardware isn't capable of remote wakeup
> [  188.959014] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [  190.469421] smsc95xx 2-2.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC1E1
> [  190.494506] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [  190.524627] Sending DHCP requests .., OK
> [  192.948425] IP-Config: Got DHCP answer from 192.168.111.1, my address is 192.168.111.32
> [  192.956604] IP-Config: Complete:
> [  192.959869]      device=eth0, hwaddr=02:02:00:a0:1f:e0, ipaddr=192.168.111.32, mask=255.2
> 55.255.0, gw=192.168.111.1
> [  192.970428]      host=beagleboard-xm, domain=muru.com, nis-domain=(none)
> [  192.977233]      bootserver=192.168.111.64, rootserver=192.168.111.64, rootpath=/srv/nfs3
> /alpine-armhf,v3,rsize=32768,wsize=32768
> [  192.977264]      nameserver0=208.69.40.3, nameserver1=208.69.40.4
> [  192.997680] VAUX3: disabling
> [  193.002410] VDAC: disabling
> [  193.007171] VUSB3V1: disabling
> [  193.010711] VPLL2: disabling
> [  193.030761] VFS: Mounted root (nfs filesystem) readonly on device 0:14.
> [  193.038635] devtmpfs: mounted
> [  193.046600] Freeing unused kernel memory: 2048K
>
> The long pause happens already before disabling unused regulators.
> So it seems more like some regression with timers or interrupts.

Ah, that would explain the fails in kernelCI.  I think we have a default
wait of 200 sec for a full kernel boot.

>> The step that seems to be happening right after MMC init is unused
>> regulators being disabled.  Is it possible that multi_v7 is missing some
>> regulator setup?
>> 
>> Also, the last line in the failure case:
>> 
>>   leds_pwm pwmleds: unable to request PWM for beagleboard::pmu_stat: -517
>> 
>> doesn't happen on the successful omap2plus_defconfig boots either.
>
> Looks like we're missing these in multi_v7_defconfig:
>
> CONFIG_PWM_TWL=y
> CONFIG_PWM_TWL_LED=y

Does the absence of these explain the super-long boot delay?   Based on
your boot, it doesn't seem like it.

Any other ideas for where the delay is coming from?

Kevin



[Index of Archives]     [Linux Memonry Technology]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux