[PATCH] usb: fix paths in usbmon documentation

[PATCH] usb: fix paths in usbmon documentation

[Rogério Brito]

Hi there.

On Aug 21 2009, Alan Stern wrote:
> On Thu, 20 Aug 2009, Rogério Brito wrote:
> > Again, just reiterating, what I said before, even though I am not sure
> > if I can reproduce it, I will try to.
> 
> A usbmon trace showing what happens when you plug in the drive and 
> when you run smartctl would help.

The documentation for usbmon in the kernel 2.6.31-rc7 kernel doesn't
match what the kernel exposes in the debug fs tree. This patch fixes it.

Signed-off-by: Rogério Brito <rbrito@ime.usp.br>

---

diff --git a/Documentation/usb/usbmon.txt b/Documentation/usb/usbmon.txt
index 6c3c625..ea05cf7 100644
--- a/Documentation/usb/usbmon.txt
+++ b/Documentation/usb/usbmon.txt
@@ -33,7 +33,7 @@ if usbmon is built into the kernel.
 
 Verify that bus sockets are present.
 
-# ls /sys/kernel/debug/usbmon
+# ls /sys/kernel/debug/usb/usbmon
 0s  0u  1s  1t  1u  2s  2t  2u  3s  3t  3u  4s  4t  4u
 #
 
@@ -58,11 +58,11 @@ Bus=03 means it's bus 3.
 
 3. Start 'cat'
 
-# cat /sys/kernel/debug/usbmon/3u > /tmp/1.mon.out
+# cat /sys/kernel/debug/usb/usbmon/3u > /tmp/1.mon.out
 
 to listen on a single bus, otherwise, to listen on all buses, type:
 
-# cat /sys/kernel/debug/usbmon/0u > /tmp/1.mon.out
+# cat /sys/kernel/debug/usb/usbmon/0u > /tmp/1.mon.out
 
 This process will be reading until killed. Naturally, the output can be
 redirected to a desirable location. This is preferred, because it is going


-- 
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

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

[Rogério Brito]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

Hi, Alan.

On Aug 21 2009, Alan Stern wrote:
> A usbmon trace showing what happens when you plug in the drive and
> when you run smartctl would help.

The requested trace is attached to this message. Please let me know if
you need more information.


Thanks, Rogério Brito.

-- 
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

[-- Attachment #2: usbmon-dump.txt.bz2 --]
[-- Type: application/octet-stream, Size: 13644 bytes --]

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

[Alan Stern]

On Sat, 22 Aug 2009, [utf-8] Rogério Brito wrote:

> Hi, Alan.
> 
> On Aug 21 2009, Alan Stern wrote:
> > A usbmon trace showing what happens when you plug in the drive and
> > when you run smartctl would help.
> 
> 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.  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.  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.

So the problem has several causes.  One is that the drive is buggy (it
doesn't respond with an error code in the proper way when it receives a
command it doesn't understand).  Another is that smartctl is trying to
send commands in a form the drive can't handle.  Finally, there's the
problem about all the retries taking too long.

Perhaps you can blame the kernel for spending too much time on retries, 
but the other two are the fault of the drive and smartctl.

Alan Stern

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

[Rogério Brito]

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?

This is the 3rd USB device that I sent you some message about where  
the kernel moans about something that it doesn't understand (I can  
get you the vendor and device ids when I get home).

I will test with some other devices that I have, just to see what  
their response is. :-(

> So the problem has several causes.  One is that the drive is buggy (it
> doesn't respond with an error code in the proper way when it  
> receives a
> command it doesn't understand).  Another is that smartctl is trying to
> send commands in a form the drive can't handle.

That's probably not smartctl, but the user (me) that is telling it to  
use a given command set to check if the USB adapter understands/ 
allows pass-thru of the SMART protocol to the drive.

> Finally, there's the
> problem about all the retries taking too long.

Is there anything that could be done about this?

> Perhaps you can blame the kernel for spending too much time on  
> retries,
> but the other two are the fault of the drive and smartctl.

I understand the p-o-v of the kernel: some devices need a little bit  
more time on a retry, while others don't. There's no way to hardcode  
a once and for all behavior. It seems that an expensive solution to  
this would be to create (yet) another list of blacklisted devices  
(how many lists of quirks do we have in the kernel already---this is  
really causing some bloat, especially for some embedded devices). :-(

OTOH, creating blacklists seem to not be the adequate (let alone  
"right") solution (see the ASUS/it87 monitoring cause) in many  
situations. :-/


Thanks for your always kind messages, Rogério Brito.

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

[Alan Stern]

On Sun, 23 Aug 2009, Rogério Brito wrote:

> > 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?

There's no way to log the invalid responses because the kernel doesn't
realize they are invalid.  However the resets _do_ get logged; you can
see them in the logs you sent.

> > 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?

There are some... but a lot of them mess it up.  :-(

> This is the 3rd USB device that I sent you some message about where  
> the kernel moans about something that it doesn't understand (I can  
> get you the vendor and device ids when I get home).
> 
> I will test with some other devices that I have, just to see what  
> their response is. :-(

Be sure to get usbmon traces.

> > So the problem has several causes.  One is that the drive is buggy (it
> > doesn't respond with an error code in the proper way when it  
> > receives a
> > command it doesn't understand).  Another is that smartctl is trying to
> > send commands in a form the drive can't handle.
> 
> That's probably not smartctl, but the user (me) that is telling it to  
> use a given command set to check if the USB adapter understands/ 
> allows pass-thru of the SMART protocol to the drive.

Yes, it's entirely possible that this adapter does not understand the 
pass-thru protocol you tried.  Isn't there more than one such protocol?

> > Finally, there's the
> > problem about all the retries taking too long.
> 
> Is there anything that could be done about this?

The length of each timeout is adjustable in sysfs, but I don't remember 
what attribute file you need to change.

Also, you could follow the instructions in those stack dumps.  They are
only warnings, not errors, and you can prevent the kernel from issuing
them.

> > Perhaps you can blame the kernel for spending too much time on  
> > retries,
> > but the other two are the fault of the drive and smartctl.
> 
> I understand the p-o-v of the kernel: some devices need a little bit  
> more time on a retry, while others don't. There's no way to hardcode  
> a once and for all behavior. It seems that an expensive solution to  
> this would be to create (yet) another list of blacklisted devices  
> (how many lists of quirks do we have in the kernel already---this is  
> really causing some bloat, especially for some embedded devices). :-(
> 
> OTOH, creating blacklists seem to not be the adequate (let alone  
> "right") solution (see the ASUS/it87 monitoring cause) in many  
> situations. :-/
> 
> 
> Thanks for your always kind messages, Rogério Brito.

You're welcome.

Alan Stern

Re: [Bugme-new] [Bug 14020] New: Stack trace when running smartctl on 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

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

[Rogério Brito]

Hi, People.

On Sep 01 2009, Alan Stern wrote:
> Should this bug report be closed out?

Please, just wait a little bit more. I'm just getting recovered from
being ill (my health is not very good, unfortunately).

That with some network (and e-mail) outages made things difficult. I'm
just getting back now.

I'm going to test the suggestion from Douglas right now.


Thanks, Rogério Brito.

-- 
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org