>> 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 <s...@chromium.org> wrote: > +Julius, who may have more comment > > Hi Marshall, > > On Mon, Aug 19, 2013 at 4:41 PM, Marshall Ha <mars...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot