Hi Alan!
On Sam, 27 Mai 2006, Alan Stern wrote:
> > - 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
It was only for your info, someone asked me about this.
> > - 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.
Yum, the timeout is in sd.c and this is in the kernel and not modular,
and I didn't install the old kernel again. Point taken.
> I'm not sure this is meaningful. You were also getting resets at almost
> one-minute intervals before cp returned.
True, esp. see below
> That should not have happened. Unfortunately there isn't enough
> information here to tell what went wrong.
So lets forget it.
> 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.
It is not repeatable. Dont ask me what it was.
> 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.
Ok, thanks for the info.
> 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.
Yup done. Nice ... I still get a lot of resets, but the copying time is
much much better!!! What before took around 45min, now takes only
10min. Seems to be that the reset time is just gone. The resest are now
were tight:
01:28:09
01:28:09
01:28:13
01:28:27
01:28:50
01:28:52
01:29:18
01:29:30
01:29:35
01:29:37
01:29:49
01:29:53
01:29:56
01:30:16
01:30:20
01:30:29
01:31:00
01:34:10
01:35:04
01:35:38
01:35:40
01:36:07
01:36:12
01:36:16
01:36:19
01:36:22
01:36:39
01:36:44
01:37:01
01:37:07
01:37:13
01:37:17
01:37:20
01:37:43
01:37:49
01:37:55
01:37:59
01:38:00
01:38:08
01:38:26
01:38:27
But the device seems to cope with this without any problems. So it is
not the rebooting of the device, nor the disk is hanging, it is just the
reset timeout from sd.c. Aha.
Do you need the usbmon output of it ... it is big, uncompressed 156M.
> Did you say that these resets occur while reading from the drive, or do
> they happen only when you are writing?
Both reading and writing.
I will be on and off till next sunday since I have a congress. So don't
expect any immediate answers from me.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <preining AT logic DOT at> Università di Siena
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
SCULLET (n.)
The last teaspoon in the washing up.
--- Douglas Adams, The Meaning of Liff
-------------------------------------------------------
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
