Re: RPI2: Mutex related KASSERT when entering ddb(4)

[Stephan <stephanwib%googlemail.com@localhost>]

Hi

Was that understandable? I can also provide a photo of the screen
showing the whole stack and panic message, if required. Though I think
it´s reproducible easily.

2015-09-22 9:01 GMT+02:00 Stephan <stephanwib%googlemail.com@localhost>:
> Hi
>
> I´m running a pretty recent image of 7.0_RC3 on my RPI2. When I hit
> Strg+Alt+Esc in order to enter ddb(4), a mutex related assertion
> fires, ending up in a crash.
>
> The assertion is in sys/dev/usb/usbdi.c
>
> KASSERT(mutex_owned(pipe->device->bus->lock)); (line 950, in usbd_start_next())
>
>
> The stack indicates an USB transfer in polling mode, originating
> somewhere from ukbd(4). The top of the stack is this:
>
> vpanic()
> __udivmoddi4()
> usbd_start_next()
> dwc2_softintr()
> ...
> dwc2_poll()
> usbd_dopoll()
> ukbd_cngetc()
> ...
>
> From looking at the code, I would expect to see usb_tranfer_complete()
> being called from dwc2_softintr(), which then calls usbd_start_next().
> usb_transfer_complete() is however missing on the stack trace and I´m
> not sure why that is.
>
> I suspect this branch was taken in usb_transfer_complete() which
> doesn´t deal with the bus lock, and usbd_start_next() expects it being
> held:
>
>     if (!repeat) {
>         /* XXX should we stop the queue on all errors? */
>         if (erred && pipe->iface != NULL)    /* not control pipe */
>             pipe->running = 0;
>         else
>             usbd_start_next(pipe);
>     }
>
> I´m not an USB guy so I don´t really understand what this all is. I
> hope someone can fix this.
>
>
> Regards,
>
> Stephan