On Thu, 2009-02-26 at 18:18 -0700, Pete Zaitcev wrote: > Interesting. Did you verify that the timeouts are set in correct > units there, seconds versus milliseconds? Remember, Alan Stern > suggested it. > They are. I have one timeout that is being incorrectly set on my compile (it's set to 500 uSec, but shows up on the stack as 1 uSec when I trap the function call) but I think that's a tool chain issue for me. > Well, here's what's going on. Even in the "ok" trace, not everything > is ok. Sometimes, this happens: > > 23:09:34.651842 ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbfae58c8) = -1 EAGAIN (Resource temporarily unavailable) > So, I suspect that for some reason the device needs a few milliseconds > to settle after the halt clear. If next transfer hits right, it stops > responding completely (like in your busted trace), or eventually recovers > (like in the trace above). The issue is confused by libusb being retarded. > Such is the theory for now anyway. > > Please try to add a delay after halts into the btool and see it that helps. > I was generous and gave the device 100,000 micro seconds to settle. And boom (using your word!) all was well. It runs btool correctly, it syncs correctly and it's happy. And that's a solution that should be generic across the universe of devices we have to play with. I'll send Chris a patch based on his latest version and we can move forward from there. Thanks a lot for the quick (and thorough) response -- Paul > -- Pete -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
