HS USB errors on OMAP3530

HS USB errors on OMAP3530

[Ashwin Bihari]

Greetings,

I've got a OMAP3530 based board on which I'm having some trouble with
HS USB transfers. I plug in a HS USB Flash drive and it is properly
detected. I can mount the drive and write any amount of data to it
without any problems. However, when I start reading from the drive,
the action halts at some random point with the USB driver indicating
that it got less data than it requested in it's transaction.

Once this failure occurs, the port gets reset and the inserted Flash
drive is "detected" again but none of the descriptors can be retrieved
to actually configure/enumerate the device. After a few more reset
cycles the process just halts. The console messages are the
following..

--- Console Messages ---
<7>usb-storage: waiting for device to settle before scanning
scsi 0:0:0:0: Direct-Access              USB DISK 2.0     PMAP PQ: 0 ANSI: 0 CCS
sd 0:0:0:0: [sda] 964608 512-byte hardware sectors (494 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] 964608 512-byte hardware sectors (494 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Assuming drive cache: write through
sda: sda1
sd 0:0:0:0: [sda] Attached SCSI removable disk
usb 1-2: reset high speed USB device using ehci-omap and address 2
usb 1-2: device descriptor read/64, error -110
usb 1-2: device descriptor read/64, error -110
usb 1-2: reset high speed USB device using ehci-omap and address 2
usb 1-2: device descriptor read/64, error -110
usb 1-2: device descriptor read/64, error -110
usb 1-2: reset high speed USB device using ehci-omap and address 2
usb 1-2: device not accepting address 2, error -110
usb 1-2: reset high speed USB device using ehci-omap and address 2
usb 1-2: device not accepting address 2, error -110
usb 1-2: USB disconnect, address 2
sd 0:0:0:0: Device offlined - not ready after error recovery
Result: hostbyte=0x01 driverbyte=0x00
end_request: I/O error, dev sda, sector 775288
end_request: I/O error, dev sda, sector 775288
Result: hostbyte=0x01 driverbyte=0x00
end_request: I/O error, dev sda, sector 775528
end_request: I/O error, dev sda, sector 775528
usb 1-2: new high speed USB device using ehci-omap and address 3
usb 1-2: device descriptor read/64, error -110
usb 1-2: device descriptor read/64, error -110
usb 1-2: new high speed USB device using ehci-omap and address 4
usb 1-2: device descriptor read/64, error -110
usb 1-2: device descriptor read/64, error -110
usb 1-2: new high speed USB device using ehci-omap and address 5
usb 1-2: device not accepting address 5, error -110
usb 1-2: new high speed USB device using ehci-omap and address 6
usb 1-2: device not accepting address 6, error -110
hub 1-0:1.0: unable to enumerate USB device on port 2
--- End Messages --

Why the writes succeed without any issues while the reads fail has me
completely stumped. I'm currently using The Linux Kernel version
2.6.24.7 from omapzoom.org with the /drivers/usb code from the latest
2.6.26 back-ported. Attempting to jump to the newest Kernel would
require some work to get my board-specific code all happy and I'm in
the process of doing that..

I would love to hear from ideas on what might be going on and what I
should be looking at to get this resolved.

Regards
~ Ashwin

Re: HS USB errors on OMAP3530

[David Brownell]

On Thursday 07 August 2008, Ashwin Bihari wrote:

> sd 0:0:0:0: [sda] Attached SCSI removable disk
> usb 1-2: reset high speed USB device using ehci-omap and address 2
> usb 1-2: device descriptor read/64, error -110
> usb 1-2: device descriptor read/64, error -110
> usb 1-2: reset high speed USB device using ehci-omap and address 2
> usb 1-2: device descriptor read/64, error -110
> usb 1-2: device descriptor read/64, error -110
> usb 1-2: reset high speed USB device using ehci-omap and address 2
> usb 1-2: device not accepting address 2, error -110
> usb 1-2: reset high speed USB device using ehci-omap and address 2
> usb 1-2: device not accepting address 2, error -110
> usb 1-2: USB disconnect, address 2
> sd 0:0:0:0: Device offlined - not ready after error recovery
> Result: hostbyte=0x01 driverbyte=0x00
> end_request: I/O error, dev sda, sector 775288
> end_request: I/O error, dev sda, sector 775288
> ...

I wouldn't assume this is specifically an OMAP issue -- though
it might be in this case.  If you could throw a USB sniffer at
the problem and report what that shows, it may be enlightening...

Folk have been reporting these symptoms for some time, but
nobody can quite track it down.  I think one person who was
able to observe the problem (I've never seen it) reported that
switching disk, USB cable, *OR* PC host made the problem go
away ... but MS-Windows didn't see it on the same hardware.

As I recall, one person had some recent success shrinking the
"let SET_ADDRESS settle" mdelay in drivers/usb/hub.c (near
line 2535).  Strictly speaking, that shouldn't be needed.

- Dave

Re: HS USB errors on OMAP3530

[Ashwin Bihari]

On Thu, Aug 7, 2008 at 3:38 PM, David Brownell <david-b@pacbell.net> wrote:
> On Thursday 07 August 2008, Ashwin Bihari wrote:
>
>> sd 0:0:0:0: [sda] Attached SCSI removable disk
>> usb 1-2: reset high speed USB device using ehci-omap and address 2
>> usb 1-2: device descriptor read/64, error -110
>> usb 1-2: device descriptor read/64, error -110
>> usb 1-2: reset high speed USB device using ehci-omap and address 2
>> usb 1-2: device descriptor read/64, error -110
>> usb 1-2: device descriptor read/64, error -110
>> usb 1-2: reset high speed USB device using ehci-omap and address 2
>> usb 1-2: device not accepting address 2, error -110
>> usb 1-2: reset high speed USB device using ehci-omap and address 2
>> usb 1-2: device not accepting address 2, error -110
>> usb 1-2: USB disconnect, address 2
>> sd 0:0:0:0: Device offlined - not ready after error recovery
>> Result: hostbyte=0x01 driverbyte=0x00
>> end_request: I/O error, dev sda, sector 775288
>> end_request: I/O error, dev sda, sector 775288
>> ...
>
> I wouldn't assume this is specifically an OMAP issue -- though
> it might be in this case.  If you could throw a USB sniffer at
> the problem and report what that shows, it may be enlightening...
>
> Folk have been reporting these symptoms for some time, but
> nobody can quite track it down.  I think one person who was
> able to observe the problem (I've never seen it) reported that
> switching disk, USB cable, *OR* PC host made the problem go
> away ... but MS-Windows didn't see it on the same hardware.
>
> As I recall, one person had some recent success shrinking the
> "let SET_ADDRESS settle" mdelay in drivers/usb/hub.c (near
> line 2535).  Strictly speaking, that shouldn't be needed.
>
> - Dave
>

Dave,

I did use a Total Phase Beagle 480USB protocol analyzer when this
issue first manifested, but there is nothing that jumped out at me as
a possible error or glitch. It just looks like the transactions just
stopped mid-way without any rhyme or reason.

I've noticed this issue with a couple of HS flash drives, as well as,
a FS CD-ROM drive.

Would the "let SET_ADDRESS settle" change only affect the initial
detection? My initial insertion of device works great, the errors I
showed are after I do a read of a large amount of data from the Flash
drive and essentially wedge something in the USB stream.

Regards
~ Ashwin

Re: HS USB errors on OMAP3530

[David Brownell]

On Thursday 07 August 2008, Ashwin Bihari wrote:
> I did use a Total Phase Beagle 480USB protocol analyzer when this
> issue first manifested, but there is nothing that jumped out at me as
> a possible error or glitch. It just looks like the transactions just
> stopped mid-way without any rhyme or reason.

Why don't you post such a log, ideally with matching Linux kernel
log data.  Maybe something would jump out to other folk.  :)


> I've noticed this issue with a couple of HS flash drives, as well as,
> a FS CD-ROM drive.
> 
> Would the "let SET_ADDRESS settle" change only affect the initial
> detection? My initial insertion of device works great,

Good.


> the errors I 
> showed are after I do a read of a large amount of data from the Flash
> drive and essentially wedge something in the USB stream.

What I'd like to establish is whether this is a case of the flash
drive flaking out (that does happen on low end hardware!) or else
there's something wrong on the Linux side.

- Dave