On Sunday 18 December 2005 08:32 am, Alan Stern wrote: > > 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. >
Probably a hardware bug then, I suppose. The device is connected directly to the back port with what looks like a well-shielded cable, and also the other device (the flash based MP3 player) is using a different cable entirely. > 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. You're right, I was looking at the wrong spot in the logs. Here's an error sequence. You're right though, it doesn't give much further insight: usb-storage: *** thread awakened. usb-storage: Command READ_10 (10 bytes) usb-storage: 28 00 06 68 1d 57 00 00 08 00 usb-storage: Bulk Command S 0x43425355 T 0x990 L 4096 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 4096 bytes, 1 entries usb-storage: Status code -71; transferred 0/4096 usb-storage: -- unknown error usb-storage: Bulk data transfer result 0x4 usb-storage: -- transport indicates error, resetting usb 3-2: reset high speed USB device using ehci_hcd and address 2 usb-storage: usb_reset_device returns 0 usb-storage: scsi cmd done, result=0x70000 usb-storage: queuecommand called usb-storage: *** thread sleeping. > > 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. Ok, I'll try that and see if it gives anything useful. > > 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. Hmm, it's looking like I might have a bunk card then. > > 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 I'll try the card in a Mac and see if I can read the same files from there. I can try the card in a different Linux machine as well. If it worked there, wouldn't that just mean there was some problem with the PCI bus? -- "We're not really interested in tearing you up with the scratches and cuts tonight. We're more interested in... educating you for the future... " - Derrick May ------------------------------------------------------- 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
