On Sat, Dec 18, 2010 at 08:39:12PM -0500, Alan Stern wrote: [...] > The drive may be okay, but your trace shows there's a bug in the > USB-SATA bridge. Here's the important part of the trace: > > > ffff8800555f0cc0 6553649 S Bo:2:004:2 -115 31 = 55534243 9e1f0000 00400000 80000a28 00000eb1 c0000020 00000000 000000 > > ffff8800555f0cc0 6553721 C Bo:2:004:2 0 31 > > > ffff8800bfbc8900 6553915 S Bi:2:004:1 -115 16384 < > > ffff8800bfbc8900 6554351 C Bi:2:004:1 0 16384 = 8cbdc6b4 336ff975 adce24ff d1fce563 2ee59caa c731186d ec50929a a28b2f35 > > ffff8800555f0cc0 6554375 S Bi:2:004:1 -115 13 < > > ffff8800555f0cc0 6554481 C Bi:2:004:1 0 13 = 55534253 9e1f0000 00000000 00 > > This shows a READ of 32 sectors (512 bytes/sector => 16 KB) starting at > sector 0xeb1c0. The read completed successfully. > > > ffff8800555f0cc0 6554505 S Bo:2:004:2 -115 31 = 55534243 9f1f0000 00000000 00001024 2400be01 00da0000 4fc200b0 000000 > > ffff8800555f0cc0 6554593 C Bo:2:004:2 0 31 > > > ffff8800555f0cc0 6554598 S Bi:2:004:1 -115 13 < > > ffff8800555f0cc0 6554731 C Bi:2:004:1 0 13 = 55534253 9f1f0000 00000000 00 > > This is an ATA command. I don't know its meaning, but apparently it > completed successfully. This is a vendor-specific "ATACB" command for some Cypress USB-ATA bridge chips, generated by "smartctl -d usbcypress". The particular command is ATA_SMART_CMD (0xb0), subcommand ATA_SMART_STATUS (0xda). Unfortunately, the usbcypress protocol is inherently racy - for some ATA commands (including the ATA_SMART_STATUS command) it needs to issue two consecutive ATACB commands at the SCSI level (the first command submits the ATA taskfile to the drive, the second command reads 8 bytes of the returned ATA taskfile). This was the first of these two commands. > > ffff8800555f0cc0 6554761 S Bo:2:004:2 -115 31 = 55534243 a01f0000 00e00100 80000a28 00000eb1 e00000f0 00000000 000000 > > ffff8800555f0cc0 6554843 C Bo:2:004:2 0 31 > > > ffff88010e8c99c0 6554863 S Bi:2:004:1 -115 122880 < > > ffff88010e8c99c0 17851180 C Bi:2:004:1 -121 57357 = ad4e562d 2e9303d9 e5881eeb 9e29a23f 8dff6b2b 162f75b5 c297d540 dbea0acb > > This is another READ, this time for 240 sectors. The drive sent 57357 > bytes back and then terminated the transfer. That's probably 57344 > bytes of actual data (112 sectors) followed by 13 bytes of status, > although when a transfer terminates early the device is required by the > mass-storage protocol to send a zero-length packet, which didn't happen > here. That's clearly a bug in the USB-SATA bridge. It's also worth > mentioning that the transfer didn't end until 11 seconds after it > started. Instead of this READ, the bridge expected the second ATACB command, which should return SMART status from the drive in this case. Apparently getting a READ command in this state confuses the bridge chip completely. There does not seem to be a way for userspace to submit two consecutive SCSI commands to the device without a possibility of getting a command from another source between them. Therefore the only safe way to use "-d usbcypress" is to make sure that nothing else is using the device (unmount all filesystems, etc.). However, the kernel now has internal support for the Cypress ATACB protocol - the ums-cypress.ko module, which attaches to CY7C68300 and CY7C68310 bridges instead of the standard usb-storage module, translates standard ATA_12 and ATA_16 SCSI commands to Cypress ATACB commands, and implementing this translation at the kernel level ensures that no other command can be sent to the device between the two ATACB commands. The only problem is that the device ID list (drivers/usb/storage/unusual_cypress.h) does not contain the vendor and product IDs for your device: > Bus 002 Device 004: ID 14cd:6116 Super Top Adding an entry for your device to that file and recompiling usb storage modules should make the ums-cypress module handle that USB-ATA bridge; then you should use "-d sat" instead of "-d usbcypress" to use the in-kernel translation code. On Sat, Dec 18, 2010 at 06:45:50PM +0100, Richard Schütz wrote: > NOTE: This is reproducible with another USB ATA bridge which supports > SAT (smartctl -d sat), too! This, however, looks like a completely different problem - the SAT protocol does not need back-to-back commands, everything is done with a single command which should not conflict with other commands issued before or after it. Please provide the usbmon trace for the error with "-d sat" too.
Attachment:
signature.asc
Description: Digital signature
