On 03/23/2012 03:34 PM, Sarah Sharp wrote:
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.
Interesting in that I switched to the large bulk transfers AFTER the problems
with xHCI were reported. I guess my attempts to fix the problem only made it worse.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
