On Sun, 18 Dec 2005, IT-290 {Ishmael Hallin} wrote:
> Hello,
>
>
> Recently I decided I wanted to repartition my hard drive, so I copied a lot
> of
> data to an external USB 2.0 hard drive, repartitioned the internal drive, and
> began copying data back over. I didn't experience any issues at all when
> copying all that data to the drive, but I kept getting I/O errors trying to
> read the data back in. The errors look like this:
>
> Code:
> Dec 17 02:41:50 [kernel] sd 0:0:0:0: SCSI error: return code = 0x70000
> Dec 17 02:41:51 [kernel] usb 3-1: reset high speed USB device using ehci_hcd
> and address 2
>
> This is with kernel 2.6.14-ck5, but I've also tried a vanilla kernel and had
> the same problem. I'm using a Sunix brand PCI USB 2.0 card, which uses a VIA
> chipset... the vendor of this card claims Linux support. At first I thought
> I had a problem with the hard disk itself, but upon further inspection I
> noticed that only certain files resulted in this error. The 'problem' files
> are not consistent in size - some are large, some are small. I can copy a
> 'problem' file multiple times to the disk, and each copy will result in read
> errors when doing a dd if=file of=/dev/null.
There was a similar report some time ago. One particular controller/disk
combination had trouble transmitting sectors that contained a certain byte
pattern.
These problems could be related to cabling (low-quality cables distort
certain signals in certain ways) or to bugs in the hardware. Don't forget
also the cables inside the computer case, the ones that connect the USB
ports on the front of the case to the motherboard -- vendors often use
poor-quality cables there.
> Wanting to isolate the problem further, I hooked up the HD enclosure to the
> built-in USB ports of another machine (Nforce2 chipset-based). I didn't
> experience any problems with copying these files on this machine. I also
> hooked the HD up to one of the built-in USB 1.1 ports on the machine
> experiencing the issue, and was able to read the files fine that way as well.
>
> Additionally, I copied one of the problem files to another USB 2.0 device (a
> flash-based MP3 player, incidentally using a diffirent filesystem -fat32 vs.
> the HD's Reiser3), using the Sunix card, and again I couldn't read the file
> back in. I know the files are being written okay because the MD5sums match
> the originals (compared when the drive is hooked up using USB 1.1).
>
> After experimenting with all this for some time, I went back and enabled
> verbose USB mass storage messages in the kernel. Here is some output when
> copying a 'problem' file:
>
> usb-storage: *** thread awakened.
> usb-storage: Command READ_10 (10 bytes)
> usb-storage: 28 00 06 68 1e 4f 00 00 10 00
> usb-storage: Bulk Command S 0x43425355 T 0x994 L 8192 F 128 Trg 0 LUN 0 CL 10
> usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
> usb-storage: Status code 0; transferred 31/31
> usb-storage: -- transfer complete
> usb-storage: Bulk command transfer result=0
> usb-storage: usb_stor_bulk_transfer_sglist: xfer 8192 bytes, 1 entries
> usb-storage: Status code 0; transferred 8192/8192
> usb-storage: -- transfer complete
> usb-storage: Bulk data transfer result 0x0
> usb-storage: Attempting to get CSW...
> usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
> usb-storage: Status code 0; transferred 13/13
> usb-storage: -- transfer complete
> usb-storage: Bulk status result = 0
> usb-storage: Bulk Status S 0x53425355 T 0x994 R 0 Stat 0x0
> usb-storage: scsi cmd done, result=0x0
> usb-storage: *** thread sleeping.
That's a perfectly normal transfer sequence, with no errors. You need to
find the spots where the errors occur. Although I bet they won't provide
much information beyond "a problem occurred here", which you already know.
> This appears to be fairly identical to the output when transferring an 'OK'
> file. Do I need to enable USB debug messages in addition to USB-storage
> messages?
No, but it wouldn't hurt.
> Anyway, so far it seems (from a layman's perspective) like certain
> combinations of data are causing either the PCI card or the EHCI driver to
> get confused and reset.
Not the driver. The driver doesn't even look at the data contents. It
just tells the controller where the data is in memory and lets the
controller handle the transfer.
> I haven't been able to test the card under another
> OS yet, but I may try that at some point in the future to see if this problem
> only occurs under Linux. Can anyone tell me if this is just a fluke in the
> card, or is it indicative of something else?
It's almost certainly either the card/cable combination or just the card.
You could try putting the card in a different Linux computer, if that
would be easier than using a different OS. And of course you could try
using a different cable.
Alan Stern
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
