Messages in this thread | | | Date | Tue, 2 Sep 2008 17:06:52 -0400 (EDT) | From | Alan Stern <> | Subject | Re: [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
| |