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 <stephan...@googlemail.com>:
> 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
