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

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

Hmm, I grabbed a recent HEAD kernel from nyftp.netbsd.org, but I saw
the same issue. I may have to build my own kernel to be sure the
change to usbdi.c is present.

Does it work for you?

2015-09-26 16:00 GMT+02:00 Nick Hudson <skrll%netbsd.org@localhost>:
> 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