Date: Sun, 21 Jul 2019 15:58:24 +0000 From: Robert Crowston <crowston@protonmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Raspberry Pi 4 boot hangs in sched_idletd. Message-ID: <8CXuLvQgIxwpLP0upt_kfzOMKpuEKBESlNEdQXWZcr6NNTFIzJn0piQPSRs0qxb7o5NMu3sRGJo7jpMvvbgWB0CjauTZoBNDt7PuqbDqNIU=@protonmail.com> In-Reply-To: <20190721144045.GI47193@kib.kiev.ua> References: <bZhr6z5_4M6PcYR8ZarvkmvnLEb9KLGiBgffRczi8BR8tGB4FzDhvddWuubPAJCuRfebzCJA2Uf5RSd9dUF4tNkkhRa9Pn27ruXia9s2C_M=@protonmail.com> <20190721144045.GI47193@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> Sleeping state is terminated by wakeup which happens either by timeouts > (which indeed requires working event timers) or due to explicit wakeup wh= en > the waiting wait channel is signalled (by wakeup(9)). I have seen threads resume through wakeup(), so I think that part is workin= g. > 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=3D260, newtd=3D0x0) at /skeleton/root/sandbo= x/src/sys/kern/kern_synch.c:402 402 td =3D curthread; /* XXX */ #0 mi_switch (flags=3D260, newtd=3D0x0) at /skeleton/root/sandbox/src/sys/= kern/kern_synch.c:402 #1 0xffff0000004492ac in sleepq_switch (wchan=3D0xffff00000099fba0 <intr_c= onfig_hook_list>, pri=3D<optimized out>) at /skeleton/root/sandbox/src/sys/= kern/subr_sleepqueue.c:625 #2 0xffff000000449920 in sleepq_timedwait (wchan=3D0xffff00000099fba0 <int= r_config_hook_list>, pri=3D0) at /skeleton/root/sandbox/src/sys/kern/subr_s= leepqueue.c:739 #3 0xffff0000004006bc in _sleep (ident=3D0xffff00000099fba0 <intr_config_h= ook_list>, lock=3D0xffff000000d461e0 <intr_config_hook_lock>, priority=3D0,= wmesg=3D0xffff00000080569d "conifhk", sbt=3D257698020000, pr=3D0, flags=3D256) at /skeleton/root/sandbox/src/sys/= kern/kern_synch.c:213 #4 0xffff00000042576c in boot_run_interrupt_driven_config_hooks (dummy=3D<= optimized out>) at /skeleton/root/sandbox/src/sys/kern/subr_autoconf.c:162 #5 0xffff0000003908a8 in mi_startup () at /skeleton/root/sandbox/src/sys/k= ern/init_main.c:314 #6 0xffff000000001088 in virtdone () at /skeleton/root/sandbox/src/sys/arm= 64/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_d= riven_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 l= ongest. I'll dig into the event timer side and try to figure out what inter= rupts its expecting.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8CXuLvQgIxwpLP0upt_kfzOMKpuEKBESlNEdQXWZcr6NNTFIzJn0piQPSRs0qxb7o5NMu3sRGJo7jpMvvbgWB0CjauTZoBNDt7PuqbDqNIU=>