On Mon, 6 Feb 2006, Thomas Thanner wrote: > Here the logs as requested (hopefully correct this time):
Okay, this is good. > ============================================================== > Before error occures it looks like this: > ============================================================== This part all looks normal. > ============================================================== > After error dmesg shows the following: > ============================================================== The error occurs here, during the second WRITE operation: > usb-storage: queuecommand called > usb-storage: *** thread awakened. > usb-storage: Command WRITE_10 (10 bytes) > usb-storage: 2a 00 00 00 00 3d 00 00 28 00 > usb-storage: Bulk Command S 0x43425355 T 0x16af L 20480 F 0 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 20480 bytes, 4 entries > usb-storage: Status code 0; transferred 20480/20480 > 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 0x16af R 0 Stat 0x1 > usb-storage: -- transport indicates command failure Even though all the data was transferred, the write failed. > usb-storage: Issuing auto-REQUEST_SENSE > usb-storage: Bulk Command S 0x43425355 T 0x800016af L 18 F 128 Trg 0 LUN 0 CL > 6 > 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_buf: xfer 18 bytes > usb-storage: Status code 0; transferred 18/18 > 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 0x800016af R 0 Stat 0x0 > usb-storage: -- Result from auto-sense is 0 > usb-storage: -- code: 0x70, key: 0x4, ASC: 0x4b, ASCQ: 0x0 > usb-storage: (Unknown Key): (unknown ASC/ASCQ) > usb-storage: scsi cmd done, result=0x2 > usb-storage: *** thread sleeping. > SCSI error : <5 0 0 0> return code = 0x8000002 > sdb: Current: sense key=0x4 > ASC=0x4b ASCQ=0x0 > end_request: I/O error, dev sdb, sector 61 > Buffer I/O error on device sdb1, logical block 0 > lost page write due to I/O error on sdb1 sense key=0x4 ASC=0x04b means "Hardware error, Data phase error". So something went wrong with the card reader, and it was something internal -- not connected with bad USB data or messed-up signals. Maybe the card reader has some non-standard timing requirements that the transfer violated (as you guessed); if so then it means the card reader doesn't following the USB Mass Storage specification. After this everything went wrong. After being reset, the device started returning this error code: > usb-storage: -- Result from auto-sense is 0 > usb-storage: -- code: 0x70, key: 0x2, ASC: 0x3a, ASCQ: 0x0 which means "Meadium not present". But obviously you did still have the card present in the reader. Maybe this means the problem really lies in the card and not the reader. However that wouldn't explain why it worked okay when the mouse was not attached to the hub. > dmesg logfile seems to be truncated in error case somehow, I think this is > regular behaviour? Probably you read all the up to the end of the dmesg log and no further entries had been written yet. > Another think I can definitely exclude from possible error list is cabling > and > hardware (besides motherboard). We checked different USB2.0 cabling, card > readers, mice, and hubs. The error stayed always the same. When looking at > USB2.0 signaling with an high end oscilloscope signal quality is definitely > within limits. Good. Can you try using a different computer? > I still think we have an EHCI hardware or driver timing issue here. We can > see > a correlation between low speed bandwidth an error frequency. And error > occures only when writing to device. I don't see how this could be an issue with the EHCI hardware or driver. If it were, the data would not have transferred succesfully. But it did; the device received the data okay and then returned an error status later. And as far as I know, the driver treats reads and writes exactly the same. > Another interesting aspect just occured today: when testing exactly same > setup > but with external USB2.0 harddisk instead of card reader, *no* such errors > occured! That supports my guess that the problem is in the card reader or the card. It doesn't explain why the same problem occurred with many different card readers. > Is there a general "card reader issue" with USB2.0? No. Most card readers work fine for most people. > Because meanwhile we have > tested about 6 different internal and external card readers, having all the > same problem. Those different card readers definitely had at least 4 > different > chip sets. Well, I can't tell exactly what the problem is. If you use one of those card readers with a different chip set, do you still end up getting the "sense key=0x4 ASC=0x4b ASCQ=0x0" error code or do you get something else? For now, the easiest way around the problem is not to attach the low-speed mouse to the external USB-2.0 hub. Either plug it directly into the computer or else get a USB-1.1 hub for use with the mouse. 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
