You are not logged in.
Pages: 1
In Windows I unplugged my USB stick without unmounting, even though it has non-backed-up important information on it (in other words: I'm stupid, please save me from myself). Now I can't seem to get any system to detect it. When I plug it in on Arch I get the following in dmesg:
[ 54.545575] usb 3-2: new high-speed USB device number 2 using xhci_hcd
[ 54.720712] usb 3-2: ep 0x81 - rounding interval to 128 microframes, ep desc says 255 microframes
[ 54.720724] usb 3-2: ep 0x2 - rounding interval to 128 microframes, ep desc says 255 microframes
[ 55.065470] usb-storage 3-2:1.0: USB Mass Storage device detected
[ 55.065773] scsi host6: usb-storage 3-2:1.0
[ 55.065905] usbcore: registered new interface driver usb-storage
[ 55.068040] usbcore: registered new interface driver uas
[ 77.483942] usb 3-2: reset high-speed USB device number 2 using xhci_hcd
[ 77.483985] xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1.
[ 77.484060] usb 3-2: hub failed to enable device, error -22
[ 77.643538] usb 3-2: reset high-speed USB device number 2 using xhci_hcd
[ 77.643586] xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1.
[ 77.643659] usb 3-2: hub failed to enable device, error -22
[ 77.803346] usb 3-2: reset high-speed USB device number 2 using xhci_hcd
[ 82.801139] xhci_hcd 0000:00:14.0: Command completion event does not match command
[ 82.801242] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 88.008767] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 88.211884] usb 3-2: device not accepting address 2, error -62
[ 88.371754] usb 3-2: reset high-speed USB device number 2 using xhci_hcd
[ 88.386119] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88021f5ca540
[ 88.386128] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88021f5ca588
[ 88.386144] usb 3-2: ep 0x81 - rounding interval to 128 microframes, ep desc says 255 microframes
[ 88.386149] usb 3-2: ep 0x2 - rounding interval to 128 microframes, ep desc says 255 microframesDoes anyone have a way I can recover at least some of my data?
Thank you so much for any help.
-Mitch
Offline
Step Zero is to get another (blank and/or expendable data) drive of equal or larger size and `dd` the entire block device from one to the other. Do this very carefully: dd is colloquially known as Disk Destroyer as a small typo can lead to real trouble. But it is also a lifesaver of a tool when used properly.
I suppose step Negative One would actually be to see if the drive is assigned a block device name. When you plug it in, does it show up under /dev/ as /dev/sdX where X is a letter? (/dev/sda would most often be your main internal drive, and often a usb drive would be /dev/sdb).
EDIT: as much as I am not a fan of that OS, if you haven't shut down the Windows computer since this happened, have you tried plugging it back in to the Windows box? I don't know Windows internals, but conceptually, the problem is that there were changes staged in memory that never got written out to the disk - it may be possible that those staged changes are still in memory in Windows and could be completed if the drive is reinserted.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Step Zero is to get another (blank and/or expendable data) drive of equal or larger size and `dd` the entire block device from one to the other.
well, step minus one is to try another cable.
— love is the law, love under wheel, — said aleister crowley and typed in his terminal:
usermod -a -G wheel love
Offline
Trilby wrote:Step Zero is to get another (blank and/or expendable data) drive of equal or larger size and `dd` the entire block device from one to the other.
well, step minus one is to try another cable.
...I unplugged my USB stick...
Offline
so. what exactly is that device — USB stick or USB drive ?
— love is the law, love under wheel, — said aleister crowley and typed in his terminal:
usermod -a -G wheel love
Offline
Offline
From the dmesg output I'd say you should try plugging it in a USB2 only port, also don't use cables, plug it directly on a port on the motherboard/laptop. Also make sure your system is up-to-date.
All the other advices apply: get bigger drive (I'd say twice as big), image it with ddrescue, try to recover the data with testdisk (or similar programs).
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
If it worked on all your machines and now doesn't work on any then it's probably a hardware or firmware failure. And it's not like "only" your files are corrupted and can be partially recovered; it seems that the device can't even finish registering with the USB bus. I think it may be screwed up for good.
[ 54.720712] usb 3-2: ep 0x81 - rounding interval to 128 microframes, ep desc says 255 microframes
[ 54.720724] usb 3-2: ep 0x2 - rounding interval to 128 microframes, ep desc says 255 microframesDo you have old kernel logs? Did the same messages appear in the past?
This 255 here is very suspicious. It suggests that the stick may have been in the process of overwriting some internal configuration data and it just managed to erase the flash memory holding them, but didn't finish programming it with new values. Now all bits read as 1, which confuses the device and/or USB host so badly that they can't talk to each other.
If this is the case, the only hope is in accessing the flash memory directly using some other controller and either guessing what has been overwritten and fixing it or trying to rescue data from the raw flash. It's not exactly easy, I have never done that and I wouldn't even know where to start without having the stick in my hands, but there are data recovery companies that may be able to help for some (likely serious) $$.
Last edited by mich41 (2015-06-03 15:46:19)
Offline
Thanks for all the replies; I knew this was the right place to ask.
It is indeed a stick, not a drive that uses a cable.
With it plugged into a USB2.0 port on my laptop (of which there are only 2 so I assume it's a fairly direct connection), it is not assigned a block device name. Therefore, I assume there's really nothing I can do using dd and such since I have no idea how to reach it.
I always assumed it was a firmware problem, since it would never mount as a disk on anything I plugged it into. I take it from the thread that none of you knows a way to flash/modify the firmware on a USB stick? I guess I'll search for data recovery companies so I can get my daily dose of adrenaline hearing their quote.
Thanks again for all your help.
-Mitch
Offline
I have no experience with this type of situation, but you *might* be able to access it via /dev/bus/usb/*/* - for example, in the case of when you received that dmesg output it might be /dev/bus/usb/003/002 which should be a "character special" file. You *might* be able to dd from this char-special file to another device, though I suspect dd would not get any indication of the end of the device so you'd have to specify a size or number of blocks for dd to copy. Also this is all just a bit of speculation and may not work at all.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
xHCI xhci_drop_endpoint called with disabled epThis line in your logs rather implies a failure in USB3 detection... if your stick is USB3 you might get more mileage by using a USB3 port...
If your troubles started when the stick was removed from a Windows machine then that Windows machine, in a not subsequently rebooted, not subsequently shutdown state would be your best chance for data recovery - it seems that the moment has passed, however ![]()
Whilst your Arch install seems unable to detect the stick it may be worth trying a data recovery LiveISO - there are a few such as GParted / Testdisk ... even the Ubuntu Rescue Remix may be of use.
Whilst data recovery looks increasingly unlikely and improbable you may be able to revive the stick with the HP USB Tool. Windows only tool i'm sorry to say and will destroy any further chance of recovery - so if you do plan to engage any specialist data recovery agents give it a miss
Save the stick - lose the data trade off ![]()
Sorry for your loss. Been there a few too many times myself.
Offline
Well, I guess you can try
echo 'blacklist usb-storage' >/etc/modprobe.d/blah.conf
rmmod usb-storageand then see if the stick still resets continuously or "settles down" and can be seen in lsusb output. In the latter case, you may indeed sit down with USB specs and try debugging it via /dev/bus/usb to see what triggers the resets and whether anything can be read in any way. Obviously, that's gonna take some time and effort, and may be futile if the drive lost flash translation layer data.
Asking some professionals may be a good idea, I don't really know what their capabilities are, but I suppose that they could be able to recover at least the raw flash contents, which is basically you files split into few-kilobyte chunks and shuffled; for some files that's a huge step forward. At least, they will tell you what they believe can be done.
Last edited by mich41 (2015-06-04 11:14:24)
Offline
I don't think the HP tool will be able to help with this one, it still needs the stick to register as a block device to actually do something.
I've had an USB stick go defective myself, and the symptoms were similar towards the end (see here).
You could try disassembling it, finding out the controller and re-flashing its firmware as I did, but I'm not sure re-flashing the controller firmware won't also wipe the actual memory chip.
If you go that route and end up getting your data, back it up ASAP. In my case that re-flashed stick has reverted to the defective state a few uses later.
[ Arch x86_64 | linux | Framework 13 | AMD Ryzen™ 5 7640U | 32GB RAM | KDE Plasma Wayland ]
Offline
Pages: 1