USB pen not detected

KarlsonKatuselt · 2018-01-11 12:31:54

Hi,

I removed a pendrive without unmounting it and now the system isn't detecting it. There is valuable data on it that I need to get from it. It does get detected if it's plugged in on startup (the led flashes) but nothing is created in /dev/ It also gets detected by windows but isn't mounted.

Output of

 dmesg | grep usb

before drive is inserted

[    0.565160] usbcore: registered new interface driver usbfs
[    0.567425] usbcore: registered new interface driver hub
[    0.568206] usbcore: registered new device driver usb
[    0.905420] usb 1-1: new high-speed USB device number 2 using ehci-pci
[    1.073430] usb 2-1: new high-speed USB device number 2 using ehci-pci
[    1.297448] usb 1-1.3: new full-speed USB device number 3 using ehci-pci
[    1.445447] usb 1-1.4: new high-speed USB device number 4 using ehci-pci
[    2.001436] usb 2-1.4: new high-speed USB device number 3 using ehci-pci
[    2.087034] usb-storage 2-1.4:1.0: USB Mass Storage device detected
[    2.087610] scsi host4: usb-storage 2-1.4:1.0
[    2.087870] usbcore: registered new interface driver usb-storage
[   11.498122] usbcore: registered new interface driver uas
[   11.780528] input: Webcam SC-10HDD12636P as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input7
[   11.780595] usbcore: registered new interface driver uvcvideo
[   12.684220] usbcore: registered new interface driver btusb
[   13.193439] usbcore: registered new interface driver ath3k
[   24.112526] usb 2-1.4: reset high-speed USB device number 3 using ehci-pci
[  656.089027] usb 2-1.4: USB disconnect, device number 3

output of

 lsusb

before the drive was inserted

Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0c45:64e0 Microdia 
Bus 001 Device 003: ID 0cf3:3004 Qualcomm Atheros Communications AR3012 Bluetooth 4.0
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub}}

output of

 dmesg | grep usb

after the drive was inserted:

[    0.565160] usbcore: registered new interface driver usbfs
[    0.567425] usbcore: registered new interface driver hub
[    0.568206] usbcore: registered new device driver usb
[    0.905420] usb 1-1: new high-speed USB device number 2 using ehci-pci
[    1.073430] usb 2-1: new high-speed USB device number 2 using ehci-pci
[    1.297448] usb 1-1.3: new full-speed USB device number 3 using ehci-pci
[    1.445447] usb 1-1.4: new high-speed USB device number 4 using ehci-pci
[    2.001436] usb 2-1.4: new high-speed USB device number 3 using ehci-pci
[    2.087034] usb-storage 2-1.4:1.0: USB Mass Storage device detected
[    2.087610] scsi host4: usb-storage 2-1.4:1.0
[    2.087870] usbcore: registered new interface driver usb-storage
[   11.498122] usbcore: registered new interface driver uas
[   11.780528] input: Webcam SC-10HDD12636P as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input7
[   11.780595] usbcore: registered new interface driver uvcvideo
[   12.684220] usbcore: registered new interface driver btusb
[   13.193439] usbcore: registered new interface driver ath3k
[   24.112526] usb 2-1.4: reset high-speed USB device number 3 using ehci-pci
[  656.089027] usb 2-1.4: USB disconnect, device number 3
[ 2354.846421] usb 2-1.4: new high-speed USB device number 4 using ehci-pci
[ 2354.927793] usb-storage 2-1.4:1.0: USB Mass Storage device detected
[ 2354.931545] scsi host4: usb-storage 2-1.4:1.0
[ 2377.438163] usb 2-1.4: reset high-speed USB device number 4 using ehci-pci

output of

 lsusb

after the drive was inserted

Bus 002 Device 004: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0c45:64e0 Microdia 
Bus 001 Device 003: ID 0cf3:3004 Qualcomm Atheros Communications AR3012 Bluetooth 4.0
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

It seems there is some activity on on the os part. In the journalctl it logs these events when plugging and unplugging the device from the machine:

jaan  11 12:20:18 karl-pc kernel: usb 2-1.4: new high-speed USB device number 4 using ehci-pci
jaan  11 12:20:18 karl-pc kernel: usb-storage 2-1.4:1.0: USB Mass Storage device detected
jaan  11 12:20:18 karl-pc kernel: scsi host4: usb-storage 2-1.4:1.0
jaan  11 12:20:18 karl-pc mtp-probe[2643]: checking bus 2, device 4: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4"
jaan  11 12:20:41 karl-pc kernel: usb 2-1.4: reset high-speed USB device number 4 using ehci-pci
jaan  11 12:26:35 karl-pc kernel: usb 2-1.4: USB disconnect, device number 4
jaan  11 12:26:39 karl-pc kernel: usb 2-1.4: new high-speed USB device number 5 using ehci-pci
jaan  11 12:26:40 karl-pc kernel: usb-storage 2-1.4:1.0: USB Mass Storage device detected
jaan  11 12:26:40 karl-pc kernel: scsi host4: usb-storage 2-1.4:1.0
jaan  11 12:26:40 karl-pc mtp-probe[2771]: checking bus 2, device 5: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4"

I'm not the most knowledgeable so any help will be greatly appreciated.

Trilby · 2018-01-11 12:55:37

KarlsonKatuselt wrote:

I removed a pendrive without unmounting it

Had you been writing the important data to the pendrive in that session, or had the data been written previously and it was just plugged in for reading and then removed uncleanly?

If the former there is a fair chance that the data was never actually written to the drive and you may be SOL. If the latter, then the data is almost certainly still there, but some issue from the unclean removal is preventing mounting. Unfortunately I suspect the latter as - at least in linux - removing a drive without unmounting is (although bad practice) generally harmless if the drive hadn't recently been written to.

KarlsonKatuselt · 2018-01-11 13:12:14

What happened was that I plugged it in and removed it straight away. I suspect that it was in the middle of the mounting/detecting process and I removed it in the middle of that which caused some issues with it. Unfortunately I don't know which processes take place during the detection/mounting process and therefore I don't even know where to start ducking it. There was no data being written on the disk at the moment. I suspect there is a header file or smth like that that the system uses to recognize the disk and that got corrupted. As you said I doubt that the data itself is corrupted. In the windows event viewer it give Error with event ID 411 with message:

 Device\USB\VID_090C&PID1000\041100000006382 had problem starting

while on both machines other devices are detected and mounted. I do hope there is a way to fix this or at least a way get the data from the system. If not there'll be hell to pay: my so-s research paper is on that drive and, as usual, she doesn't have a backup Thanks for the input btw.

seth · 2018-01-11 13:24:49

Run "dmesg -w", plug in the device and post the entire output that occurs as a result.

Unlike with other things, plug and immediate pull is usually safe here, notably if there're no stupid automount daemons around.
What's not safe is to use a cheap crap device (from your lsusb) as exclusive storage device.

KarlsonKatuselt · 2018-01-11 13:31:05

[ 6552.428737] usb 2-1.1: new high-speed USB device number 8 using ehci-pci
[ 6552.510027] usb-storage 2-1.1:1.0: USB Mass Storage device detected
[ 6552.513375] scsi host4: usb-storage 2-1.1:1.0
[ 6574.612415] usb 2-1.1: reset high-speed USB device number 8 using ehci-pci

These four lines got output after the device was plugged in. I'll be sure nothing like that happens again. I wasn't even aware she was doing that.

seth · 2018-01-11 14:14:31

Toast.

The system communicates with a firmware on the stick, that firmware communicates with the NAND chips which hold the actual data and brokers them to the OS. The dmesg output and the windows error indicate that firmware is not doing its job.

If you google for "smi mptool", you may find some tools (windows only; ensure to refresh your mandarin, you only *get* it from russian webpages, the SW is usually chinese - yes, it's scary) to flash/reset the firmware - chances that you can revive the stick with them are low; chances that you nuke all data on them in the effort are real.

You can also try to desolder the NAND chips from the key and put them onto an equivalent working device. You're gonna need some experience for this. (The NAND storage doesn't die so easily - it usually looses its ability to store new data - but if you're bringing a soldering iron to it, things can go south very fast ...)

IFFFFFFF you're very lucky, your plug/unplug edevor caused minor physical damage to the plug (the four copper lanes) which could be easy to fix.

Maybe she's got a half-wise recent copy in a local autosave cache on a system she used to edit the paper? Mailed it around or something?

KarlsonKatuselt · 2018-01-11 14:49:07

Unfortunately she doesn't have any backups. Of those options which would you go for? For the soldering option I'd try to find someone professional though. Also, are you aware if the people who fix phones these days will be capable of such a fix and what should I look for in the person I take it to for a fix? And thank you for your input. Now I'll only be half dead once I tell her it was the pen not me.

As for the smi mptool I found this page: https://usb-fix.blogspot.de/p/smi.html Are these the tools you had in mind? And you're right. It is scary. And thanks again for the input.

seth · 2018-01-11 15:14:05

That looks like the SMI tools (I'm not sure whether they're legally in the wild and there's probably no way to figure whether they're legit)

On a rare chance, the key might work on USBv1 (blacklist ehci_hcd, in doubt use the install /bin/false method) - but notice that this is a voodoo solution.

I'd first inspect the physical contacts, you can also break the shell and look at the plug-to-board connections.
Then see whether one of the SMI tools deals with the specific device (on an isolated windows installation which you're ok to nuke afterwards) - and pray (if the tool really just resets the firmware the data should™ survive - unfortunately we don't live in a shouldland... and the tool could simply be a virus)

The only question I'd ask any contender to re-solder the chips is: "have you successfully done this before?"
This is likely going to be expensive.
Also you're gonna need an *exact* sibling of that key - with the very same controller chip of the very same revision. You cannot just grab another random cheap throwaway key and solder the NAND chips there.

Arch Linux

#1 2018-01-11 12:31:54

USB pen not detected

#2 2018-01-11 12:55:37

Re: USB pen not detected

#3 2018-01-11 13:12:14

Re: USB pen not detected

#4 2018-01-11 13:24:49

Re: USB pen not detected

#5 2018-01-11 13:31:05

Re: USB pen not detected

#6 2018-01-11 14:14:31

Re: USB pen not detected

#7 2018-01-11 14:49:07

Re: USB pen not detected

#8 2018-01-11 15:14:05

Re: USB pen not detected

Board footer