David >Where IDLE == only SOFs are seen?
>Or the hardware idle state, by which you mean the port was suspended? IDLE==only SOFs. I confirmed that using Catalyst. >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. Sounds like a good idea. Has been already implemented in the newer kernel ? >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 did not see any errors per say. Let me explain the log again 1. Host send Class type request and device ack it. I looked at the value in the class type request and it corresponds to "reset mass storage device". The device acked it. 2. 6 seconds IDLE time on bus. Alan explained the host driver uses 6 seconds timer to let the device settle. I don't see any issue here. 3. Host send Clear endpoint feature request for in endpoint and device responds it. 4. Host send Clear endpoint feature request for out endpoint and device responds it. 5. 10 seconds IDLE time on bus. After above transactions,data transfer resumed and went on till the 30 seconds idle resurfaced. I hope this helps you. Let me know if you need more details. >That said, we could more easily change the host software. At least, if >someone with a hardware analyser could isolate the problem ... :) Agreed. Let me know if you want do more experiements using hardware analyzer. Regards Vivek -----Original Message----- From: David Brownell [mailto:[EMAIL PROTECTED] Sent: Monday, June 05, 2006 7:27 AM To: linux-usb-devel@lists.sourceforge.net Cc: Alan Stern; Vivek Dharmadhikari Subject: Re: [linux-usb-devel] Usb hangs during small and large file transfer 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
