Re: [Bugme-new] [Bug 14020] New: Stack trace when running smartctl on an USB disk

[Douglas Gilbert <dgilbert@interlog.com>]

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