lkml.org 
[lkml]   [2008]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] JMicron JM20337 USB-SATA data corruption bugfix - device 152d:2338
On Tue, 2 Sep 2008, Thiago Galesi wrote:

> > However what finally caused the failure was a command (0xAC) which I
> > don't recognize and apparently your drive doesn't recognize either.
>
> Is this it? dfbb5d80 1845367929 C Bi:6:002:1 0 13 = 55534253 acc90100
> 00000000 00

No, it was this:

dfbb5d80 1845397954 S Bo:6:002:2 -115 31 = 55534243 dac90100 08000000 80000cac 00000000 00000000 01030000 000000

The initial sign of a problem is the -104 error code about five lines
farther down in the log.

The odd thing is that the device did give an 8-byte response to that
command (as it was supposed to) but then apparently crashed and didn't
provide any status. After that everything failed.

I don't know; maybe it was just a coincidence that the failure occurred
the first time this command was used.

> Any idea who may be sending this? I mean, can this be send via a
> simple IOCTL to /dev/sr0 or it is something else?
> Maybe stracing the program would be a good idea.

Maybe. If you were trying to write a DVD during the test then almost
certainly the command was sent by an IOCTL like you said. You could
probably figure out what the command was supposed to do by looking
through the source code for the program.

> If I were to place a trace inside a driver, were would it be better?
> sr_mod, sd_mod, usb-storage, cdrom? or somewhere else?

It depends on what you want to trace. Although in this case it's safe
to ignore sd_mod since your device uses sr_mod.

Alan Stern



\
 
 \ /
  Last update: 2008-09-02 23:09    [W:0.081 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site