On Wed, 24 May 2006, Norbert Preining wrote: > Hi Alan! > > On Mit, 24 Mai 2006, Alan Stern wrote: > > The normal usb-storage debugging isn't very good for tracking down > > intermittent problems like this. However if you want, you can add your > > own printk statements to the driver to find out exactly when each reset > > starts and ends. > > Ok, I retract my statement that the reset takes so long, it takes less > than a second. I have put a printk before and another after the two > resets ( port reset and transport reset). I could only see port resets > and they usually take less than one second. Transport resets didn't > occur at all, ie. result = usb_stor_port_reset(us) always was > 0.
That's normal. Windows never uses the transport reset, as far as I know. It's in there mainly for devices with multiple interfaces, where the port-reset code won't run. > So it seems that my ls tests are not very useful. Interestingly I > observed the following: ls hangs always till there is a port reset, than > it succeeds. It looks like this: I do permanent ls -l of the target > direcory and can see the files growing with every ls -l. Then suddenly > nothing changes, and a ls -l onto other file hangs. > > Then the port reset and the other ls continues, and the ls -l shows the > files again growing. > > Maybe it is only that the hard disk needs so much time to actually safe > the data and while this time it is blocking. Possible? Or maybe the disk's firmware crashes and stops responding, but the driver waits for the current command to time out before doing a reset. I guess there's no easy way to tell the difference between a long blockage and a crash. Increase the timeout limit perhaps, and see if the resets go away. (The default timeout is defined as SD_TIMEOUT in drivers/scsi/sd.c and it is set to 30 seconds.) > I did another time run, for copying the same 30 files, each around > 230Mb to the devidce, and this time I had again 29 resets and > real 25m28.033s > user 0m0.272s > sys 0m29.250s > > I found something strange than, maybe only strange for me: > 9727 ? D 0:00 [pdflush] > 9733 ? D 0:00 [pdflush] > 9735 ? D 0:00 [pdflush] > 9736 ? D 0:00 [pdflush] > 9738 ? D 0:00 [pdflush] > 9749 ? D 0:00 [pdflush] > 9785 ? D 0:00 [pdflush] > 9788 ? D 0:00 [pdflush] > 9789 ? D 0:00 [pdflush] > 9790 ? D 0:00 [pdflush] > Hmmm... so many of them? But I have no idea about these kernel layers. > They go away when the copying is finished. I don't know either. Created by the VM subsystem, perhaps, when a lot of pages need to written out to disk. Alan Stern ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
