Re: reading errors on JMicron JM20337 USB-SATA

[Artur Skawina]

Lev A. Melnikovsky wrote:
> I have read through a year old thread on "JMicron JM20337 USB-SATA data
> corruption bugfix" and it seems here's another aspect of the same
> problem. The SATA disk has genuine errors (bad sectors, just in case: I
> am not going to use it but to recover some data from it). Unfortunately
> when a bad block is read no error is returned, instead a caller is
> blocked indefinitely (until the USB cable is removed). The system log is
> filled with repetitive
> 
> sd 3:0:0:0: [sdf] Sense Key : 0x0 [current]
> sd 3:0:0:0: [sdf] ASC=0x0 ASCQ=0x0

yes, jmicron bridges do not report errors properly and just stall pretty
much indefinitely; found out the hard way, when a disk started to develop
bad blocks. took a bit of time to figure out as there were no i/o errors
reported at all. At least all the patches from back then have been merged
and the kernel can better cope w/ the situation (it used to be a lot worse);
plus modern smartctl will let you see the smart attributes (-d usbjmicron),
making it easier to check if the disk really is failing.

What did work for my case was to copy the data from the disk and every
time the process stalled turn off power to the sata drive for a few seconds
(leaving the bridge connected). The bridge in most cases recovered and a bit
more data got off the drive.

This was what saved that controller, because by the time i realized the
disk went bad, it was not possible to even mount the fs using another sata
controller due to all the i/o errors. With the above process i was able to
recover ~95% of the data.
Summary: Wouldn't want to use the bridge for any kind of unattended data
transfer, it's more of a data recovery device...

artur
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/