Re: disconnect on one usb2.0 port corrupts the communication on the other

[Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>]

On Thu, 18 Oct 2007, Oliver Neukum wrote:

> Am Donnerstag 18 Oktober 2007 schrieb Oliver Neukum:
> > Am Mittwoch 17 Oktober 2007 schrieb Alan Stern:
> > > > switching the ports to USB 1.1 (through bios or /sys/class/usb_hub/usb_hub/companion)
> > > > avoids the error, but is not satisfying solution.
> > > > 
> > > > Does anyone know of this error and/or of an available fix /patch /workarounds?
> > > 
> > > No idea what the problem is.  Suggestions are welcome.
> > 
> > Introduce a guard time after unplugs for which reset is delayed?
> 
> OK, I should elaborate.
> 
> 1. It seems like the original fault is caused by hardware.
>    Therefore we can do nothing about it and must concentrate on error recovery.
> 2. Later on, reset must work, or we'd have bug reports about that long ago.
> 
> Therefore there should be a time window during which the hardware is
> dealing with its internal troubles due to device removal, during which we
> should not mess around with other devices.

It's not quite this simple.  I did some more testing, this time doing
the transfer through the high-speed hub to a g_file_storage gadget.  
Not surprisingly, it tends to be more robust than most other USB
storage devices.

Results varied.  I was able to provoke a couple of different BUGs in 
ehci-hcd; tracking them down will take some time because they occur in 
interrupt context and the machine just locks up.  I'll have to set up a 
serial console...

However on at least one occasion things worked more or less as
expected.  That is, the disconnect occurred while a transfer was in
progress.  A 65536-byte bulk-in transfer stopped after 64512 bytes with
error code -121, indicating that the EHCI controller thinks it received
a 0-length packet when the gadget did not send one.  This is clearly a
hardware bug; it's difficult to say whether the bug is in the
controller or in the external high-speed hub.  (Maybe I should try a 
test without the hub.)

Anyway, the following CSW transfer failed with error -75, probably 
because the gadget was still sending 512-byte bulk data packets instead 
of the expected 13-byte CSW.  The system went through a normal 
port-reset sequence, and the transfer continued without error!

This suggests that our error-recovery procedure is more or less 
correct.  The fact that it fails when a flash device is used rather 
than g_file_storage may simply indicate that the device doesn't cope 
properly with a port reset while it's in the middle of doing a 
transfer.  I don't know of any way to do a stronger kind of reset.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel