On Wed, 26 Jan 2005, Simon Cooper wrote:
> When I try to transfer large files to my usb2 external hard disk (but
> not from it) it freezes randomly for a couple of minutes then starts up
> again and the program doing the copying just carries on.
That's good! It means the error recovery procedures in usb-storage are
working right. If you don't think it's really all that good, consider the
alternative: The transfer stops dead in the middle and your system
crashes. :-)
> Recently this
> has been accompanied with complete system freezes
It's hard to say anything about why that might happen. You could try
getting a stack trace with Alt-SysRq-T during such a freeze; maybe it will
indicate what's going on.
> Jan 26 17:48:00 [EMAIL PROTECTED] usb-storage: Status code 0; transferred
> 31/31
> Jan 26 17:48:00 [EMAIL PROTECTED] usb-storage: -- transfer complete
> Jan 26 17:48:00 [EMAIL PROTECTED] usb-storage: Bulk command transfer result=0
> Jan 26 17:48:00 [EMAIL PROTECTED] usb-storage: usb_stor_bulk_transfer_sglist:
> xfer 4096 bytes, 1 entries
> Jan 26 17:48:00 [EMAIL PROTECTED] usb-storage: Status code 0; transferred
> 4096/4096
> Jan 26 17:48:00 [EMAIL PROTECTED] usb-storage: -- transfer complete
> Jan 26 17:48:00 [EMAIL PROTECTED] usb-storage: Bulk data transfer result 0x0
> Jan 26 17:48:00 [EMAIL PROTECTED] usb-storage: Attempting to get CSW...
> Jan 26 17:48:00 [EMAIL PROTECTED] usb-storage: usb_stor_bulk_transfer_buf:
> xfer 13 bytes
> Jan 26 17:48:30 [EMAIL PROTECTED] usb-storage: command_abort called
> Jan 26 17:48:30 [EMAIL PROTECTED] usb-storage: usb_stor_stop_transport called
> Jan 26 17:48:30 [EMAIL PROTECTED] usb-storage: -- cancelling URB
> Jan 26 17:48:30 [EMAIL PROTECTED] usb-storage: Status code -104; transferred
> 0/13
> Jan 26 17:48:30 [EMAIL PROTECTED] usb-storage: -- transfer cancelled
> Jan 26 17:48:30 [EMAIL PROTECTED] usb-storage: Bulk status result = 4
> Jan 26 17:48:30 [EMAIL PROTECTED] usb-storage: -- command was aborted
> Jan 26 17:48:30 [EMAIL PROTECTED] usb-storage: usb_stor_Bulk_reset called
> Jan 26 17:48:30 [EMAIL PROTECTED] usb-storage: usb_stor_control_msg: rq=ff
> rqtype=21 value=0000 index=00 len=0
>
> this doesnt happen when its forced to usb1.1
>
> any ideas? this is really causing problems...
According to the log, your hard disk or its USB interface just decided not
to send the final status of that last command. This forced a reset, which
probably took a minute or two to finish because the device was misbehaving
pretty badly.
Why doesn't it happen when running at full speed? It's probably some
timing-related issue in the USB interface. Obviously the timing
requirements are much more strict at high speed.
If you want to experiment, you could try changing the usb-storage driver
in a way that was necessary for Genesys Logic devices. Edit the source
file drivers/usb/storage/transport.c. Inside the usb_stor_Bulk_transport
subroutine you'll find a couple of lines that say:
if (le16_to_cpu(us->pusb_dev->descriptor.idVendor) ==
USB_VENDOR_ID_GENESYS)
udelay(110);
Either comment out or delete entirely the "if" line, leaving only the
udelay(110). (On your system it might say 100 instead of 110; either one
should work. Also you might be missing the le16_to_cpu part; again it
won't matter.)
Perhaps adding the extra 110- or 100-microsecond delay will allow your
device to work correctly.
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
