...

I saw that you had proposed a patch for increasing the U-Boot timeout to work with some USB flash devices:

http://lists.denx.de/pipermail/u-boot/2010-December/083467.html

Some devices do have strange characteristics, and increasing the timeout can make them work. However, it's tricky since it then makes every other device slower (if we are scanning for something that isn't there and waiting longer than we need to for 99% of the devices out there).

Looks like that patch is just about the bulk transfer timeout after a failed TEST_UNIT_READY. Increasing that shouldn't really hurt, since if we get that far we already have a device for which basic enumeration worked (and then you probably want the code to do everything it can to get it to work).

I have seen quite a few sticks that always fail their first TEST_UNIT_READY and then take very long to respond, though I'm not quite sure why (probably all using the same bad chipset/firmware). The highest I had took about 2.2 seconds, so I would set the timeout to at least 3 to be on the safe side.

AFAIK Linux uses at least 5 seconds for most USB timeouts, so it's probably well-covered for this particular problem. I think it is a specific issue for some sticks that only concerns the response time after a failed TEST_UNIT_READY (which shouldn't be issued during data transfer), so if you see other errors during heavy activity on Linux they are probably unrelated. You should use a USB analyzer or the Linux usbmon framework to have a closer look at what transfers fail why if you want to get a better idea of what's wrong.

On Mon, Aug 19, 2013 at 4:49 PM, Simon Glass sjg@chromium.org wrote:

+Julius, who may have more comment

Hi Marshall,

On Mon, Aug 19, 2013 at 4:41 PM, Marshall Ha marshha@gmail.com wrote:

...

Hi Simon,

I saw that you had proposed a patch for increasing the U-Boot timeout to work with some USB flash devices:

http://lists.denx.de/pipermail/u-boot/2010-December/083467.html

I have also ran into this problem in U-Boot, with the same root cause. I realize that this mailer is primarily for U-Boot, but I was curious whether this was an issue that you had encountered only in U-Boot, or whether you had also observed this problem after booting into an operating system. For example, I have observed that once booted into Linux, the USB devices will return I/O errors after heavy read/write activity, which I suspect to have the same root cause.

I believe this code was merged into U-Boot - or at least in Chrome OS I'm not aware of any patches to this code that remain (on top of mainline) other than the USB3 work.

Some devices do have strange characteristics, and increasing the timeout can make them work. However, it's tricky since it then makes every other device slower (if we are scanning for something that isn't there and waiting longer than we need to for 99% of the devices out there).

So either you have found a real bug in U-Boot and Linux, or the device is broken. I'm not sure which, but it is worth investigating with an open mind.

Regards, Simon

...

Thanks, Marshall