On Fri, 28 Sep 2012, Don Zickus wrote: > > Probably the device was already hung. The log showed that an earlier > > transfer completed with a STALL. The reason wasn't apparent, although > > a usbmon trace might give a clue. It might also show why the device > > had to be reset. > > Here is the output of 'cat 4u' > ffff880240121860 3207118259 S Bo:4:002:3 -115 31 = 55534243 6c000000 00000000 00000600 00000000 00000000 00000000 000000 > ffff880240121860 3207118359 C Bo:4:002:3 0 31 > > ffff880240121860 3207118430 S Bi:4:002:4 -115 13 < > ffff880240121860 3207118511 C Bi:4:002:4 0 13 = 55534253 6c000000 00000000 00 > ffff880240121860 3207127088 S Bo:4:002:3 -115 31 = 55534243 6d000000 00020000 80000ca1 082e0001 00000000 ec000000 000000 > ffff880240121860 3207127197 C Bo:4:002:3 0 31 > > ffff880240122698 3207127238 S Bi:4:002:4 -115 512 < > ffff880240122698 3207143925 C Bi:4:002:4 -32 0 > ffff880240121860 3207144021 S Co:4:002:0 s 02 01 0000 0084 0000 0 > ffff880240121860 3207220654 C Co:4:002:0 -32 0 > ffff880240122698 3207220814 S Co:4:001:0 s 23 03 0004 0004 0000 0 > ffff880240122698 3207226644 C Co:4:001:0 0 0 This shows that the problem began when the device was sent a command it didn't recognize: 0xA1, which is a 12-byte ATA pass-through, in this case for an IDENTIFY DEVICE command (0xEC). Presumably the Western Digital device doesn't support ATA pass-through. The device halted its bulk-IN endpoint and then replied with a STALL to the Clear-Endpoint-Halt request (which is an invalid response). This is why the reset was tried. Don, what does a comparable usbmon trace look like when the drive is attached to an EHCI controller? I would expect to see basically the same thing. 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
