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
