On Thu, Mar 22, 2012 at 09:24:31PM -0500, Larry Finger wrote: > On 03/22/2012 05:31 PM, Sarah Sharp wrote: > > >Larry, if the driver doesn't cancel an URB that the device doesn't > >respond to, then it will just be left on the endpoint ring. If the > >driver then tries to queue new transfers to that same endpoint, but the > >device keeps NAKing the uncancelled transfer, then the endpoint ring > >would fill up with unanswered transfers. > > > >Perhaps some userspace or kernel portion is forgetting to cancel URBs > >before moving onto the next thing? You said you moved to asynchronous > >transfers, so maybe the problem lies there? > > The writes have always been asynchronous and reads are synchronous. > The only change was to convert the firmware uploading writes from > 32-bits at a time into block writes of 1000+ 32-bit words. Yeah, that's going to cause the out-of-room warning under xHCI. That should be fixed in the 3.4-rc1 kernel though. > Would xhci be worse that ohci or ehci in terms of the device not > responding to URBs? We only see problems with USB3.0 hubs, never > with 2.0 or 1.1. That's because EHCI handles arbitrarily large transfers, and xHCI didn't until now. > I am looking into changing the writes to be synchronous. That should > clear up any problems. Yeah, your problem probably was in the bulk large transfer, not the unfinished canceled URBs. I would suggest getting your reporters to just try 3.4-rc1 and see if it helps before doing too much work to debug this. Sarah Sharp -- 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
