usb/93496: USB2.0 umass stalls on VIA

[Ian Dowse]

In message <144860699.20060321130714 at cmtk.net>, Wesha the Leopard writes:
>Hello Ian,
>
>Friday, February 24, 2006, 10:49:05 PM, you wrote:
>
>ID> Could you try updating to 6-stable? There are new workarounds in
>ID> place for interrupt loss on VIA controllers.
>
>I tested 6.0-RELEASE with 6.0-CURRENT usb subtree patch on the
>production box, and it still stalls. See the log below. Again, this is
>*WITH* all USB changes (including ehci) from -current.

Thanks for the update. It would be useful if you could apply the
following change to ehci.c to get more information - sorry, you'll
need to apply it manually as I've just pasted it from a larger diff:

@@ -2666,8 +2738,11 @@
 
	DPRINTF(("ehci_timeout: exfer=%p\n", exfer));
 #ifdef USB_DEBUG
-	if (ehcidebug > 1)
+	if (ehcidebug > 1) {
		usbd_dump_pipe(exfer->xfer.pipe);
+		ehci_dump_sqh(epipe->sqh);
+		ehci_dump_sqtds(epipe->sqh->sqtd);
+	}
 #endif
 
	if (sc->sc_dying) {

I now have one hardware configuration here where I can reproduce
stalls with a VIA VT6202 and a USB 2.0 flash drive, but I've been
unable so far to find the cause - in my case the flash drive completes
a normal umass BBB transfer and returns the BBB status block, but
then the next BBB command times out and the drive never responds
again to anything, including reset requests. Interestingly out of
two different USB 2.0 hubs I have, connecting the flash drive through
one particular hub seems to make the stalls go away, but not if I
use the other one, and the drive seems to work fine on an Intel
EHCI controller.

There are however quite a few other areas where the ehci driver is
not following the specification, such as in the way it appends new
transfer descriptors to queue heads, so hopefully a patch for one
of those issues might help you. The debug output from the patch
above will at least indicate whether the request that timed out
was properly set up by the driver.

Ian