Rogério Brito wrote:
Hi again, Alan.
(Sorry if this message seems messed up, but I am not using my regular
mailer right now, unfortunately).
On 2009-08-22, at 21:17, Alan Stern wrote:
On Sat, 22 Aug 2009, Rogério Brito wrote:
The requested trace is attached to this message. Please let me know if
you need more information.
The trace shows that something (presumably smartctl) sends a command
the drive doesn't understand. The drive then violates the USB
mass-storage protocol, sending an invalid response.
Right.
The kernel waits
for a proper response but nothing more happens, so after 30 seconds the
command times out and is aborted and the drive is reset.
I'm not with the kernel sources here (so, I can't check the code), but
is there any option to be able to log such invalid responses when the
kernel gets one? Perhaps the verbose USB logging does that?
The command
then gets retried, and the same thing happens again. The retries take
so long that the kernel complains about smartctl being blocked for more
than 120 seconds -- that's the reason for the stack dump.
Right.
Geeez, Alan, is there any vendor out there that gets the USB
implementation according to the specs?
The fact that you invoked:
smartctl -d usbcypress -a /dev/sda
means that the cypress chip does not comply with SAT.
To find out what commands are being sent (via the SG_IO
ioctl I presume) by smartctl please try adding:
'-r ioctl,3'
to the above invocation.
Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
