On Sat, 30 Jan 2010, Klaus Doblmann wrote: > thanks, Greg! mounted debugfs (yes, they include it ;) ) and captured > the plugging in (+30seconds or so afterwards to see the LED blink > meaning an attempted mounting took place) with usbmon. See the attached > log. > Please do note: The drive I captured uses a JMicron chipset as I have > found the bug affecting this drive in the exact same way as the one I > initially wrote about and it's one I don't need right now so I can use > it for all kinds of tests ;) > > Device info (in case it helps): > > T: Bus=02 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 11 Spd=480 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=152d ProdID=2329 Rev= 1.00 > S: Manufacturer=JMicron > S: Product=USB to ATA/ATAPI Bridge > S: SerialNumber=DCAF3034069F > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 2mA > I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 > Driver=usb-storage > E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
