Re: Transmitting payload and ATA commands simultaneously messes up connection with USB SATA bridge

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/19/10 02:39, 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.

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

Looks like these stupid bridges are faulty often then. My other external drive handles reading data and querying SMART fine, but gets crazy when data is written and SMART queried then. Since this is apparently a hardware problem virtually nothing can be done against it, right?

P.S. I'm still wondering why my e-mail including the trace only reached Alan and not the list so far. I got no error message as well.

--
Regards,
Richard Schütz
--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux