well, at least on this hardware it happened with great consistency (100% of the attempts, (at least 20)) immediately upon attempting to setup the device. i think it happened right after opening the data endpoints (but without any data needing to be sent to trigger it) On Fri, Dec 6, 2013 at 4:35 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 6 Dec 2013, Felipe Balbi wrote: > >> Hi, >> >> On Fri, Dec 06, 2013 at 04:08:21PM -0500, palesius . wrote: >> > In working on a project (http://github.com/dominicgs/USBProxy) we ran >> > across an issue where io on endpoint 0 would cause the system to hang. >> > >> > We made the following change which resolved the problem for us. I'm >> > not sure if this is the "correct" fix, or if the problem is specific >> > to our platform BeagleBone Black with a musb-hrdc controller. >> > >> > --- inode.c 2013-11-18 14:46:25.255029000 -0500 >> > +++ inode.c2 2013-11-19 06:30:36.579029000 -0500 >> > @@ -679,7 +679,9 @@ >> > req->length = len; >> > req->complete = ep_aio_complete; >> > req->context = iocb; >> > + spin_unlock_irq(&epdata->dev->lock); >> > value = usb_ep_queue(epdata->ep, req, GFP_ATOMIC); >> > + spin_lock_irq(&epdata->dev->lock); >> >> usb_ep_queue() should be able to be called from atomic. Do you have some >> dumps of the problem ? when BBB hangs, can you dump the stack ? (If >> you're using minicom -> CTRL + A + F + P should work). > > I suspect the problem is that with some UDC drivers, under some > circumstances, a transfer can complete _during_ the usb_ep_queue() > call. The driver copies the data from the request buffer into a > hardware FIFO, and if it all fits, goes ahead and invokes the > transfer's completion routine. > > Of course, the completion routine attempts to acquire the spinlock, and > hangs. > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
