On Sun, Dec 19, 2010 at 02:08:51PM +0100, Richard Schütz wrote: [...] > The cause for the problem with my other external drive must be a > different one then. > > More details on that: > > lsusb -v: > Bus 002 Device 020: ID 1e68:001b TrekStor GmbH & Co. KG DataStation maxi g.u [...] > It looks like there's a JMicron chip inside, but "smartctl -d > usbjmicron" fails. Reading data from the drive and querying SMART with > "smartctl -d sat" works without problem. Writing data and then querying > SMART results in errors. > > kernel errors: http://richard.qasl.de/kernel.log > usbmon trace: http://richard.qasl.de/2.mon.out Now let's look at this trace: > ffff880072debc00 31732710 S Bo:2:021:2 -115 31 = 55534243 c30d0000 00e00100 00000a2a 00253e3a 000000f0 00000000 000000 > ffff880072debc00 31732800 C Bo:2:021:2 0 31 > > ffff8800268de6c0 31732808 S Bo:2:021:2 -115 122880 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > ffff8800268de6c0 31736678 C Bo:2:021:2 0 122880 > > ffff880072debc00 31736689 S Bi:2:021:1 -115 13 < > ffff880072debc00 31736793 C Bi:2:021:1 0 13 = 55534253 c30d0000 00000000 00 This is a WRITE_10 (0x2a) command, writing 240 sectors (122880 bytes) at LBA 0x253e3a00 (624835072); it has completed successfully. > ffff880072debc00 31736858 S Bo:2:021:2 -115 31 = 55534243 c40d0000 00020000 80001085 080e0000 00010000 00000000 00ec00 > ffff880072debc00 31736918 C Bo:2:021:2 0 31 > > ffff8800268de6c0 31736928 S Bi:2:021:1 -115 512 < > ffff8800268de6c0 31755057 C Bi:2:021:1 0 512 = 7a42ff3f 37c81000 00000000 3f000000 00000000 20202020 57202d44 4d575a41 > ffff880072debc00 31755067 S Bi:2:021:1 -115 13 < > ffff880072debc00 31755170 C Bi:2:021:1 0 13 = 55534253 c40d0000 00020000 00 This is an ATA_16 (0x85) command - SAT protocol (ATA passthrough). The ATA command inside is IDENTIFY (0xec) - read the drive identification block; protocol specified in SAT command is PIO Data-in, USB storage command block requests input of 512 bytes. The identification block seems to be returned correctly (and apparently the drive inside was made by WD); however, in the status block the device replies that there are still 512 data bytes not transferred - this is strange. > ffff880072debc00 31755206 S Bo:2:021:2 -115 31 = 55534243 c50d0000 00e00100 00000a2a 00253e3a f00000f0 00000000 000000 > ffff880072debc00 31755294 C Bo:2:021:2 0 31 > > ffff8800268de6c0 31755304 S Bo:2:021:2 -115 122880 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > ffff8800268de6c0 31759176 C Bo:2:021:2 0 122880 > > ffff880072debc00 31759187 S Bi:2:021:1 -115 13 < > ffff880072debc00 31759293 C Bi:2:021:1 0 13 = 55534253 c50d0000 00020000 00 This is a WRITE_10 (0x2a) command, writing 240 sectors (122880 bytes) at LBA 0x253e3af0 (624835312). The device replied with "no error", but again reports a residue of 512 bytes. > ffff880072debc00 31759315 S Bo:2:021:2 -115 31 = 55534243 c60d0000 00e00100 00000a2a 00253e3a f00000f0 00000000 000000 > ffff880072debc00 31759418 C Bo:2:021:2 0 31 > > ffff8800268de6c0 31759428 S Bo:2:021:2 -115 122880 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > ffff8800268de6c0 31763284 C Bo:2:021:2 0 122880 > > ffff880072debc00 31763291 S Bi:2:021:1 -115 13 < > ffff880072debc00 31763405 C Bi:2:021:1 0 13 = 55534253 c60d0000 00020000 00 The same WRITE_10 command is retried, but the result does not change - a 512-byte residue is reported again. Then the same command is retried again (6 tries total) - no changes. Finally the SCSI layer gives up and moves on to next WRITE_10 commands, which also return the same 512-byte residue - apparently the device is wedged completely. Could you also get an usbmon trace when you first issue "smartctl -d sat" on an otherwise idle device, and then do some writes to it? Maybe the device returns a wrong residue even in this case, but then subsequent commands issued by smartctl reset the bad state. One possible option is to ignore the bad residue by using the US_FL_IGNORE_RESIDUE flag for the device - the 0x152d, 0x2329 JMicron bridge is already in drivers/usb/storage/unusual_devs.h with quirk flags US_FL_IGNORE_RESIDUE | US_FL_SANE_SENSE, maybe this device needs such workarounds too. This can be tested without rebuilding the kernel by specifying an additional parameter for the usb-storage module: quirks=1e68:001b:ar ("echo 1e68:001b:ar > /sys/module/usb_storage/parameters/quirks" should work even without reloading the module). BTW, the usbjmicron proprietary passthrough protocol seems to have the same fundamental deficiency as the usbcypress protocol (requires two consecutive commands to get the full result taskfile), except the implementation in smartctl avoids the second command by using a workaround for the "SMART STATUS" command, and not supporting other commands needing the full result taskfile at all.
Attachment:
signature.asc
Description: Digital signature
