Raspberry Pi 4 boot hangs in sched_idletd.

Robert Crowston crowston at protonmail.com
Sun Jul 21 15:58:31 UTC 2019


> Sleeping state is terminated by wakeup which happens either by timeouts
> (which indeed requires working event timers) or due to explicit wakeup when
> the waiting wait channel is signalled (by wakeup(9)).

I have seen threads resume through wakeup(), so I think that part is working.

> But really you should start examining the sleep chain of the thread0 and
> see which exact condition it waits for.

That's a helpful insight.

> You did not even provided the backtrace for it.

Breakpoint 8, mi_switch (flags=260, newtd=0x0) at /skeleton/root/sandbox/src/sys/kern/kern_synch.c:402
402             td = curthread;                 /* XXX */
#0  mi_switch (flags=260, newtd=0x0) at /skeleton/root/sandbox/src/sys/kern/kern_synch.c:402
#1  0xffff0000004492ac in sleepq_switch (wchan=0xffff00000099fba0 <intr_config_hook_list>, pri=<optimized out>) at /skeleton/root/sandbox/src/sys/kern/subr_sleepqueue.c:625
#2  0xffff000000449920 in sleepq_timedwait (wchan=0xffff00000099fba0 <intr_config_hook_list>, pri=0) at /skeleton/root/sandbox/src/sys/kern/subr_sleepqueue.c:739
#3  0xffff0000004006bc in _sleep (ident=0xffff00000099fba0 <intr_config_hook_list>, lock=0xffff000000d461e0 <intr_config_hook_lock>, priority=0, wmesg=0xffff00000080569d "conifhk",
sbt=257698020000, pr=0, flags=256) at /skeleton/root/sandbox/src/sys/kern/kern_synch.c:213
#4  0xffff00000042576c in boot_run_interrupt_driven_config_hooks (dummy=<optimized out>) at /skeleton/root/sandbox/src/sys/kern/subr_autoconf.c:162
#5  0xffff0000003908a8 in mi_startup () at /skeleton/root/sandbox/src/sys/kern/init_main.c:314
#6  0xffff000000001088 in virtdone () at /skeleton/root/sandbox/src/sys/arm64/arm64/locore.S:142
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

The final time I see we are on thread0, we are running boot_run_interrupt_driven_config_hooks, which looks like it has a sixty second delay. It's not the first or the last sleepq_timedwait in the boot, but it's probably the longest. I'll dig into the event timer side and try to figure out what interrupts its expecting.


More information about the freebsd-arm mailing list