Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



On 09/22/15 08:01, Stephan wrote:
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.

cvs update and try again. The locking is not required when polling.

Nick


Home | Main Index | Thread Index | Old Index