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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4A9188EA.2080903@interlog.com>
Date:	Sun, 23 Aug 2009 14:22:34 -0400
From:	Douglas Gilbert <dgilbert@...erlog.com>
To:	Rogério Brito <rbrito@....usp.br>
CC:	Alan Stern <stern@...land.harvard.edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-usb@...r.kernel.org, linux-scsi@...r.kernel.org,
	linux-kernel@...r.kernel.org, bugzilla-daemon@...zilla.kernel.org
Subject: Re: [Bugme-new] [Bug 14020] New: Stack trace when running smartctl
 on an USB disk

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/