Port-arm archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
RPI2: Mutex related KASSERT when entering ddb(4)
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
Home |
Main Index |
Thread Index |
Old Index