On Fri, 26 May 2006, Norbert Preining wrote: > Dear Alan! > > On Fre, 26 Mai 2006, Alan Stern wrote: > > UNUSUAL_DEV( 0x1006, 0x3003, 0x0100, 0x0100, > > "iRiver", > > "H300 Series", > > US_SC_DEVICE, US_PR_DEVICE, NULL, > > US_FL_GO_SLOW ), > > Ok, didn't change anything.
Too bad. So much for that idea. > But I have some more obervations: > > - the usb control interface works, lsusb -v does work all the time > and the stuff is seen in usbmon It's not uncommon for one part of a USB interface (the part that handles standard control requests) to continue working while another part (the part that controls the disk drive) fails. > - before the resets happen there is a 1min break where nothing comes over > the data channel. Nothing, nothing shows up in the usbmon window > besides the lsusb -v data. That's because the computer is waiting for a response from the drive. After the SD_TIMEOUT interval (which you changed to 1 minute instead of 30 seconds) the command is aborted and the device is reset. > - the same happens when reading from the device: for one minute nothing > happens, then the reset. > - while the copy process was running the data was shipped sometimes > longer sometimes shorter to the device. > After cp finished, I called sync, and then the resets occured > immediately, ie in 1min interval. See the time stamps: > 19:12:19 > 19:13:22 > 19:17:26 > 19:19:28 > 19:20:49 > 19:22:24 > 19:23:29 > 19:25:37 > 19:26:42 > 19:28:02 > 19:29:17 > 19:30:40 > 19:32:01 > 19:33:05 > 19:34:44 > 19:36:10 > 19:37:38 > 19:38:41 > 19:39:43 > 19:41:04 > 19:42:07 > 19:43:16 > 19:44:22 > 19:45:26 > 19:46:34 > cp returned, I called sync > 19:48:02 > 19:49:03 > 19:50:07 > 19:51:08 > 19:52:09 > 19:53:11 I'm not sure this is meaningful. You were also getting resets at almost one-minute intervals before cp returned. > the few seconds extra are for the stuff transfered but this was only > a very short time. > - after this it happened that I unplugged the device from the usb port > to redo the test on a different port, and what happened, everything > usb stuck. lsusb hanged in D state: That should not have happened. Unfortunately there isn't enough information here to tell what went wrong. To really know where the problem was, it will be necessary to see the log with CONFIG_USB_DEBUG and CONFIG_USB_STORAGE debug both set and also to see the stack traces for the following tasks: khubd, usb-storage, and scsi_eh_0. > > With that entry in place, there will be a visible 125 us delay in the > > usbmon log between the completion of each 31-byte command block and the > > submission of the following 4096-byte data transfer. > > I guess you mean this: > da277840 3574210563 S Bo:003:01 -115 31 = 55534243 15060100 00e00100 00000a2a > 000478c6 950000f0 00000000 000000 > da277840 3574210672 C Bo:003:01 0 31 > > da277bc0 3574210820 S Bo:003:01 -115 4096 = e3e2be4f a4a888bc d7a7a254 > 02b5534f 277919a9 baa15c93 78dfe0aa 71a1e683 Yes. This proves that the unusual_devs entry was written correctly. > Some ideas/questions: > - Can we increase the waiting time between control and data transfer? > I think the really time-stopper is this strange one-minute delay > (where the harddrive is rebooting or whatever), if we can avoid this > then all the devices would be happier. Those are two different delays. I don't think there's any point in increasing the control/data delay, although you can try changing it if you want. It is the udelay() statement in transport.c:usb_stor_Bulk_transport(). You can replace it with msleep() for as many milliseconds as you like. > - Do I have to get nervous about my drive with all these tests/resets? > And if yes, we should definitely fix this so that no other devices > get fried/grilled/barbecued. The resets should not hurt the drive at all; they ought to be less harmful than unplugging the USB cable. The tests shouldn't be dangerous either, since they involve nothing more than copying data to or from the drive. > - Is this 1-minute stuff only in my imagination??? No, obviously not. > - What else can I do for you? Try reverting all the patches you have made except the one that adds msleep() after the line setting srb->result. Instead of calling msleep, have it goto Handle_Errors. Did you say that these resets occur while reading from the drive, or do they happen only when you are writing? 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
