[ale] USB thumb drive recovery

[Michael H. Warfield]

On Mon, 2011-07-25 at 11:36 -0400, Jeff Hubbs wrote: 
> Got a thumb drive here whose existence doesn't even get acknowledged by 
> Windows or OS X - plug it into Linux and I see the likes of:
> 
> [3640680.025026] ohci_hcd 0000:00:13.0: GetStatus roothub.portstatus [0] 
> = 0x00100103 PRSC PPS PES CCS
> [3640680.076032] usb 1-1: new full speed USB device using ohci_hcd and 
> address 10
> [3640680.077079] ohci_hcd 0000:00:13.0: urb ffff880076850180 path 1 
> ep0out 5ec20000 cc 5 --> status -62
> [3640680.278077] ohci_hcd 0000:00:13.0: urb ffff880076850180 path 1 
> ep0out 5ec20000 cc 5 --> status -62
> [3640680.479042] usb 1-1: device not accepting address 10, error -62
> [3640680.541034] ohci_hcd 0000:00:13.0: GetStatus roothub.portstatus [0] 
> = 0x00100103 PRSC PPS PES CCS
> [3640680.592032] usb 1-1: new full speed USB device using ohci_hcd and 
> address 11
> [3640680.593068] ohci_hcd 0000:00:13.0: urb ffff880076850180 path 1 
> ep0out 5ec20000 cc 5 --> status -62
> [3640680.794066] ohci_hcd 0000:00:13.0: urb ffff880076850180 path 1 
> ep0out 5ec20000 cc 5 --> status -62
> [3640680.995049] usb 1-1: device not accepting address 11, error -62
> [3640680.995081] hub 1-0:1.0: unable to enumerate USB device on port 1
> [3640680.995092] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0002

> I know this suggests a bad controller chip - the LED on the thumb drive 
> never comes on.  I've tried taking it out of its enclosure, pressing 
> down on all the little SMD components, plugging it in while flexing the 
> PC board this way and that - no change.

Had that happen with one that accidentally went through the drier.
Several pins of the the memory SMC were no longer soldered!

> I've got a quote of $200-1000 from a place that wouldn't be able to 
> unsolder/resolder SMD chips locally (which makes me think it wouldn't be 
> any $200 when all is said and done) - anyone know any other options?

You didn't say.  Is there valuable data on that key you did not back up?

If you just want to recover a key to reuse it, I've done that.  In
testing a number of things, I've destroyed and recovered several keys
(resulting in more than one kernel patch).  If you want to recover data,
you may be in really deep doo.  Simply moving the memory chip from one
controller to another may not even be enough.  I'm not sure where the
flaw list and the wear leveling logic is stored.  The NAND ROM itself, I
thought, was just dumb memory.  The controller has to track what block
is mapped to what LBA address and to rotate blocks through the wear
leveling so that no one block gets rewritten too often (like the bloody
FAT tables).  Plug it into a new controller, even an identical
controller, and how does it know what was what?  I'm not optimistic
there.

If you don't care about the data...  Most of my keys that I blew up
(mostly due to the "SYNC" option on the FAT/VFAT file systems which has
now been nuked) I recovered simply by dd'ing /dev/zero over the key.
Those failed keys all recovered and are all now back in use.  That SYNC
option on the VFAT mount resulted in the Linux kernel whacking off on
the FAT tables which, on cheap keys, eventually caused them to crash.
Copying a 1G file to a VFAT file system would do it and give errors very
similar to what you described.  The kernel was rewriting both the FAT
and the backup FAT on each block write and, in addition to it taking
forever, eventually caused a failure on the NAND ROM that the cheap
controllers didn't catch.  The overwrite of /dev/zero forced the
controller to flaw those NAND ROM blocks out and so I lost a few spares
by the keys work again.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110725/4bdb118e/attachment.bin