panic: deadlres_td_sleep_q: possible deadlock detected on RPI3

[Kyle Evans]

On Fri, Jan 31, 2020 at 6:26 AM Ralf Wenk <iz-rpi03 at hs-karlsruhe.de> wrote:
>
> On 2020-01-30 at 8:20 -0800  bob prohaska wrote:
> > On Sun, Jan 26, 2020 at 08:42:11AM -0800, bob prohaska wrote:
> > > On Sun, Jan 26, 2020 at 11:31:47AM +0100, Ralf Wenk wrote:
> > > >
> > > > I got this panic two times in a row with a r357112 kernel during
> > > > make installworld at the same place. So it looks like I am able to
> > > > reproduce it.
> > > >
> > > > # panic: deadlres_td_sleep_q: possible deadlock detected for
> > > >   0xfffffd0000f33560, blocked for 1802833 ticks
> > > >
> > > > But I think it is just a symptom of the r356776 changes.
> > > >
> > > > > Attempts to reboot are also rebuffed with
> > > > > cpu_reset failed
> > > > > leaving a power cycle as the only option, which is new to me.
> > > > >
> > > > > Does this give any hints as to what's going on?
> > > >
> > > > After doing the update from r356767 to r356776 my system began to
> > > > show the "cpu_reset failed" message as well.
> > > >
> > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243464
> > > >
> > >
> > My Pi3 still panics at r357204, but ntp seems to work fine.
> > One other oddity: During the loader countdown to boot, time
> > seems to run about 5x slower than it should, each second
> > on the screen taking about five seconds. The string
> > deadlres_td_sleep_q turns up in sys/kern/kern_clock.c,
> > might there be a connection between the panic and the
> > very slow boot countdown?
>
> In my experience this behavior depends on
> /boot/msdos/EFI/BOOT/bootaa64.efi.
>
> How "fast" time is ticking in the loader also depends here if the
> beastie menu is disabled or not. With bootaa64.efi from 5 of December
> and disabled beastie menu, time is ticking like realtime. With enabled
> beastie menu time is jumping. Frequently from -6 seconds to immediately
> boot.
>

These results should no longer be reproducible in recent loaders --
the effect you're seeing is an extraordinarily long redraw times as
that's roughly in the range where serial console in loader was
effectively borked. Things were later hashed out such that we use the
old console driver for serial in many (most? all?) situations.

Thanks,

Kyle Evans