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-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
