Re: kern/56050 (xhci suspend/resume is unimplemented)

[Andrius V <vezhlys%gmail.com@localhost>]

The main suspicion came for me on while loop condition changes starting line 3198:
    while (sc->sc_command_addr != 0 &&
        sc->sc_suspender != NULL &&
        sc->sc_suspender != curlwp)

And it seems to be actually the culprit for the issue now: seemingly it goes into infinite loop and likely locks the device. Because of that usbd_delay_ms() times out without "getting" new address and assertion fails on 2901 line (as per my backtrace). I didn't have time today to check what are the values, but removing newly added sc->sc_suspender checks makes the system boot successfully again.

On Wed, May 26, 2021 at 1:59 PM Andrius V <vezhlys%gmail.com@localhost> wrote:
>
> No, it happens consistently on every boot right after that commit. I
> tested kernels commit by commit, all previous ones boot without
> issues. Yes, I don't suspend/resume, not sure why it affects booting
> process.
>
> On Wed, May 26, 2021 at 1:45 PM <maya%netbsd.org@localhost> wrote:
> >
> > The following reply was made to PR kern/56050; it has been noted by GNATS.
> >
> > From: maya%NetBSD.org@localhost
> > To: gnats-bugs%netbsd.org@localhost
> > Cc: netbsd-bugs%netbsd.org@localhost, nia%pkgsrc.org@localhost
> > Subject: Re: kern/56050 (xhci suspend/resume is unimplemented)
> > Date: Wed, 26 May 2021 10:41:47 +0000
> >
> >  On Wed, May 26, 2021 at 09:15:02AM +0000, Andrius V wrote:
> >  > The following reply was made to PR kern/56050; it has been noted by GNATS.
> >  >
> >  > From: Andrius V <vezhlys%gmail.com@localhost>
> >  > To: gnats-bugs%netbsd.org@localhost
> >  > Cc: kern-bug-people%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
> >  >      nia%netbsd.org@localhost, Taylor R Campbell <riastradh%netbsd.org@localhost>
> >  > Subject: Re: kern/56050 (xhci suspend/resume is unimplemented)
> >  > Date: Wed, 26 May 2021 12:09:45 +0300
> >  >
> >  >  The latest xhci.c rev 1.140 changes are causing panic in my system if
> >  >  any xhci device (or at least with my USB stick and/or external SSD) is
> >  >  connected. The previous commit still works (suspend/resume draft).
> >  >  Interestingly enough and probably irrelevant, the kernel does not
> >  >  crash with serial console boot on 115200 speed (still fails on default
> >  >  9600 speed though).
> >  >
> >
> >  xhci.c 1.140 only touches suspend/resume code, and you don't seem to be
> >  suspending in this dmesg.
> >
> >  I suspect this is a spurious panic that happens sometimes.
> >