Date: Mon, 22 Jul 2019 07:19:29 +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: <ndOgYsI5BnUOvzymuXkhA2HhOUkKCsS0CYl5RemlCF-REEJ02ltecPw89guemxTKIiXUNhOYkDQHjJgIn3hSeSAhBsio-WwJgrSHpf-GQeM=@protonmail.com> In-Reply-To: <20190721160551.GK47193@kib.kiev.ua> References: <bZhr6z5_4M6PcYR8ZarvkmvnLEb9KLGiBgffRczi8BR8tGB4FzDhvddWuubPAJCuRfebzCJA2Uf5RSd9dUF4tNkkhRa9Pn27ruXia9s2C_M=@protonmail.com> <20190721144045.GI47193@kib.kiev.ua> <8CXuLvQgIxwpLP0upt_kfzOMKpuEKBESlNEdQXWZcr6NNTFIzJn0piQPSRs0qxb7o5NMu3sRGJo7jpMvvbgWB0CjauTZoBNDt7PuqbDqNIU=@protonmail.com> <20190721160551.GK47193@kib.kiev.ua>
index | next in thread | previous in thread | raw e-mail
I figured it out: when I patched armstub8.bin to enable PSCI, I didn't bring in a #DEFINE from upstream required to enable the GIC on the cpu. With that done, timercb fires, the callout that boot_run_interrupt_driven_config_hooks() was waiting for happens, and I get as far as the mount root prompt. Next weekend I'll work on the SD card driver. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, 21 July 2019 17:05, Konstantin Belousov <kostikbel@gmail.com> wrote: > 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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ndOgYsI5BnUOvzymuXkhA2HhOUkKCsS0CYl5RemlCF-REEJ02ltecPw89guemxTKIiXUNhOYkDQHjJgIn3hSeSAhBsio-WwJgrSHpf-GQeM=>