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

[Douglas Gilbert]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/