Alan >I am curious also. It should never happen.
Earlier you indicated that there is a 30 second timer in scsi module. Can this timer play any role here ? Pardon me if this sounds a silly question as don't know about scsi. >The usb-storage driver pauses for 6 seconds to give the device time to >settle after being reset. Ok. I now understand the reason for 6 second delay on the wire. >A bug in the driver or an error in the controller hardware. You said >earlier that you ported the 2.6.12 driver to a MIPS SOC machine. Maybe >your port has a bug or maybe the Synopsys USB 2.0 controller has an >erratum. Yes, I ported the 2.6.12 driver to MIPS SOC. The USB host controller is not interfaced to PCI bus and therefore i used the notion of platform device to port the driver. The porting involved writing code for platform devices and that about it. Nevertheless, I will double check the ported code and erratum for Synopsys USB 2.0 controller. Regards Vivek -----Original Message----- From: Alan Stern [mailto:[EMAIL PROTECTED] Sent: Saturday, June 03, 2006 9:34 AM To: Vivek Dharmadhikari Cc: David Brownell; USB development list Subject: RE: [linux-usb-devel] Usb hangs during small and large file transfer On Fri, 2 Jun 2006, Vivek Dharmadhikari wrote: > Alan > > >The problem is more likely to be in your device than in the kernel. > > You are proabably right here. I used Catalyst USB analyzer to cross > check the results of usbmon log. USB analyzer indicated many hot spots > of 30 seconds and 6 seconds which are in aggrement with usbmon log. > > >The 30-second jump occurs because the device has crashed and isn't sending > >any response. The kernel waits for 30 seconds before aborting the > >command. The 6-second jump is probably part of the device-reset sequence. > > However the 30 seconds delay was not due to device crash but rather due > to NYET handshake packet from device. The 6 second jump occurs after > Class type request. The sequence on the bus is like below int the order > given below > > Host send OUT transcation with 31 Bytes > Device reponds with NYET. > 30 seconds IDLE time on bus. > 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. > I used USB 2.0 hard disk from Iomega,acomdata and 2.0 flash driver from > Sandisk for the experiments and i saw similar patterns with each one of > them. > > I am curious to know condition under which the host will observe silence > for 30 seconds. I ask because the analyzer shows that many a > times,device responded with NYET and host then initiated PING > transactions immediately(after few milliseonds) after NYET which is ok. I am curious also. It should never happen. > Similarly why the host obeserve silence for 6 seconds after sending > class type request ? The usb-storage driver pauses for 6 seconds to give the device time to settle after being reset. > I don't think the hard disks are bad because they works fine with Windows. I agree. The problem is in the host. > I also repeated the above experiments by attaching the hard disks to 1.0 > hub,there by forcing the hard disks to operate at full speed.I did not > see idle time greater than 1 seconds and copy operation finished much > earlier than the devices operating at high speed !. I am baffled by this > fact. Do you any theory here ? A bug in the driver or an error in the controller hardware. You said earlier that you ported the 2.6.12 driver to a MIPS SOC machine. Maybe your port has a bug or maybe the Synopsys USB 2.0 controller has an erratum. If there is a bug in the driver, perhaps it has already been fixed in later versions of the kernel. Alan Stern _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
