On Thu, Mar 08, 2012 at 09:59:07PM -0600, Larry Finger wrote: > On 03/08/2012 09:28 PM, jerome huang wrote: > > > >It still got no any result if I wait for 30 sec (or longer) between > >(original) step 2 and 3. > >I double confirmed that it always does not work for steps: plugin -> > >up -> scanning > >and always works for steps: plugin -> up -> down -> up -> scanning. > > > >And sometimes it works for next down->up->scanning, sometimes it doesn't. > > > >Is the change of firmware loading in kernel 3.3 made by rtlwifi only, > >or ring expansion in xhci is also necessary? > > The only changes are in the rtlwifi drivers. I don't have a USB 3 > device, thus I have no idea what might work there. I wrote something > incorrect earlier. The new code is not in mainline 3.3, but it is in > the wireless-testing git tree. If you want to try this, and don't > want to get the whole tree, the new code is in the bleeding-edge > compat-wireless package. Otherwise, I could send you the patches. 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? Jerome, the xHCI ring expansion patches have been merged for 3.4, so you can test with Linus' latest tree and see if they help. If the ring expands indefinitely, then there's probably an issue with the rtlwifi drivers. 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
