Am Samstag, den 30.01.2010, 21:48 -0500 schrieb Alan Stern: > The usbmon trace shows the problem clearly, although it doesn't show > the source of the problem. Things start to go wrong here: > > > ffff88001b083e40 2655717029 S Bo:2:015:2 -115 31 = 55534243 21000000 00000000 00001085 06200005 00fe0000 00000000 40ef00 > > ffff88001b083e40 2655717090 C Bo:2:015:2 0 31 > > > ffff88001b083e40 2655717123 S Bi:2:015:1 -115 13 < > > ffff88001b083e40 2655731738 C Bi:2:015:1 0 13 = 55534253 21000000 00000000 00 > > ffff88001b083e40 2655732007 S Bo:2:015:2 -115 31 = 55534243 22000000 00020000 80001085 082e0000 00000000 00000000 40ec00 > > ffff88001b083e40 2655732099 C Bo:2:015:2 0 31 > > > ffff8800afe263c0 2655732126 S Bi:2:015:1 -115 512 < > > ffff8800afe263c0 2655748859 C Bi:2:015:1 -121 13 = 55534253 22000000 00020000 00 > > ffff88001b083e40 2655748906 S Bi:2:015:1 -115 13 < > > ffff88001b083e40 2663266469 C Bi:2:015:1 -104 0 > > The shows a sequence of two ATA pass-through commands being sent to the > device. I don't know what those commands are or what program was > responsible for sending them; as far as I'm aware nothing in the kernel > will do it. Perhaps some program started by udev is responsible. > Looking through your udev rules might pinpoint the culprit. Thanks very much, Alan, it sure is great to finally have a point where I can start looking for the cause. Klaus > > Anyway, the first command doesn't seem to cause any difficulty, but the > second command fails completely. Instead of sending data in its > response, the device sends a status message. The kernel gets this, > thinks it is data, and then waits for the status to come -- which of > course never happens. So the kernel resets the device and tries > issuing the same command again, with the same result. > > Alan Stern >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
