Re: USB Mass Storage devices continually reenumerate

On Fri, 2 Nov 2007, Mike Nuss wrote:

> This isn't really a Linux specific question anymore, but I'm using
> Linux to debug it. I've managed to more specifically identify the
> issue but I could still use some help interpreting the data.
> 
> I've spliced the cable so that the VBUS line is tied directly to a 5V
> source, pretty much eliminating power issues.  I unloaded the SCSI
> disk driver and I'm using sg to issue single commands to the device.
> Occasionally in the middle of a command, I see the disconnect.
> 
> The disconnect is always in the middle of an IN transfer.  On a
> digital scope I can see D+/D- going low for about 10ms, so it's a real
> disconnect and not noise.  I believe that 10ms is the delay that the
> OHCI hardware would use to reset a port.

That's right, if you haven't enabled CONFIG_USB_SUSPEND.  If you have 
then the reset duration is 50 ms.

Note, however, the a reset is different from a disconnect.  What you 
see on the scope is a reset and not a disconnect.

> The command I've been testing with is READ CAPACITY. I've observed the
> traffic on a bus analyzer. When the command succeeds, the process is:
> 
> Host sends OUT
> Host sends DATA containing CBW
> Device ACKs
> Host sends IN
> Device sends DATA containing the response (capacity)
> Host ACKs
> Host sends IN
> Device sends DATA containing CSW
> Host ACKs
> 
> When it fails, the failure is always the same, on the second IN. The
> device sends the CSW, but the host never ACKs. After ~250ms, I see the
> 10ms reset, and the device comes back.

Apparently the host controller never sees the DATA packet.

> It sure looks like the HC is resetting the port for some reason.
> ohci-hcd reports that the TD failed with an error count of 3, which
> seems inconsistent because I would expect to see multiple INs if that
> were the case. I thought it might be detecting a babble, but the
> device's response is within microseconds of the IN token so I don't
> see how it could be past the end of the frame.

That is strange indeed.  Yes, there should be 3 copies of the IN 
packet if the error count is 3.

> Any idea what could be causing this? I know "buggy hardware" is the
> obvious answer but I'm trying to determine exactly what the bug is.

I can explain part of it.  After failure to receive the CSW,
usb-storage always calls for a device reset.  That explains why you see
the reset signal on the bus.  Whether or not a "logical disconnect"  
then occurs will depend on how the device behaves following the reset.

It certainly sounds like a hardware bug in the host controller.  It's 
as though the controller becomes unable to transmit or receive any data 
over the USB bus for a sort time.

There's one thing you can try which might work around the problem.  
Edit drivers/usb/storage/transport.c, and change all three occurrences
of US_BULK_CS_WRAP_LEN to 64.  You'll also have to comment out the "if"  
statement following the third occurence.  Perhaps the controller will
work better if asked to transfer a full-sized packet instead of just 13
bytes.

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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel