Date: Sun, 21 Jul 2019 19:05:51 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Robert Crowston <crowston@protonmail.com> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Raspberry Pi 4 boot hangs in sched_idletd. Message-ID: <20190721160551.GK47193@kib.kiev.ua> In-Reply-To: <8CXuLvQgIxwpLP0upt_kfzOMKpuEKBESlNEdQXWZcr6NNTFIzJn0piQPSRs0qxb7o5NMu3sRGJo7jpMvvbgWB0CjauTZoBNDt7PuqbDqNIU=@protonmail.com> References: <bZhr6z5_4M6PcYR8ZarvkmvnLEb9KLGiBgffRczi8BR8tGB4FzDhvddWuubPAJCuRfebzCJA2Uf5RSd9dUF4tNkkhRa9Pn27ruXia9s2C_M=@protonmail.com> <20190721144045.GI47193@kib.kiev.ua> <8CXuLvQgIxwpLP0upt_kfzOMKpuEKBESlNEdQXWZcr6NNTFIzJn0piQPSRs0qxb7o5NMu3sRGJo7jpMvvbgWB0CjauTZoBNDt7PuqbDqNIU=@protonmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 21, 2019 at 03:58:24PM +0000, Robert Crowston wrote: > > 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. Wakeup(9) itself most likely work, otherwise you would not get to the mount root stage of boot. What did not worked, probably, is some specific event which occurence causes wakeup for intr_config_hook. There, only you can inspect the state and see why it did not happen. > > > 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. It is almost certainly not the eventtimers issue.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190721160551.GK47193>