On Saturday 03 June 2006 9:33 am, Alan Stern wrote: > On Fri, 2 Jun 2006, Vivek Dharmadhikari wrote: > > > > Host send OUT transcation with 31 Bytes > > Device reponds with NYET. > > 30 seconds IDLE time on bus.
Where IDLE == only SOFs are seen? Or the hardware idle state, by which you mean the port was suspended? > > Host send Class type request and device ack it. > > 6 seconds IDLE time on bus. > > Host send Clear endpoint feature request for in endpoint and device > > responds it. > > Host send Clear endpoint feature request for out endpoint and device > > responds it. > > 10 seconds IDLE time on bus. > > > > The above sequence gets repeated few times during the copy operation to > > USB hard disk and copy operation take long time to finish. > > Aha! It's a good thing you had the Catalyst. This does look like a bug > in the host controller driver, or maybe an erratum in the controller > itself. If EHCI had sane timer handling, it would be easier to add code doing things like forcing endpoints out of NYET mode every few seconds. For paranoia's sake, it would be good to verify more of the interactions with the host. The previous request and response especially ... did they trigger an error of some kind? If so, how was it recovered from? > > I don't think the hard disks are bad because they works fine with Windows. > > I agree. The problem is in the host. Not clear. If the issue is that Windows has more/better error handling idioms, why should it always be the fault of Linux if a peripheral just likes to issue those errors ... say, instead of behaving correctly? That said, we could more easily change the host software. At least, if someone with a hardware analyser could isolate the problem ... :) - Dave _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
