On Sat, 18 Dec 2010, Richard Schütz wrote: > >> I'm not sure if this is a common problem of this SATA USB bridges (as > >> it's reproducible with my other and different external drive, too) or a > >> problem with the USB stack and/or the usb-storage driver handling this > >> situation which needs to be fixed. > > > > Most probably it is not a problem in the kernel, meaning it _is_ a bug > > in the SATA-USB bridge or the drive. You can get more information by > > recording a usbmon trace of a failure; see the kernel source file > > Documentation/usb/usbmon.txt. > > > > Alan Stern > > > > I recorded an usbmon trace of the incident and attached it. A bug in the > drive is very unlikely, because this happens with different drives and > works fine if they are connected directly via SATA. 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. > 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. > ffff8800555f0cc0 17851303 S Bi:2:004:1 -115 13 < > ffff8800555f0cc0 37147160 C Bi:2:004:1 -104 0 This shows the computer waiting for the 13 status bytes and not receiving anything. After 20 seconds it gave up and cancelled the status transfer... > ffff8801376f2300 37147197 S Co:2:001:0 s 23 03 0004 0001 0000 0 > ffff8801376f2300 37147204 C Co:2:001:0 0 0 and then reset the drive. The reset worked okay, but the drive refused to transfer any more data afterward. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
