• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Reviving a dead Samsung 840 Pro

fury

Limp Gawd
Joined
Dec 22, 2002
Messages
352
Have an 840 Pro 256 GB with a lot of data on it that I would hate to lose.

The drive failed randomly on me Wednesday, and guess who doesn't have backups? Yeap, I am competing for dumbfuck of the year award. The most frustrating thing to me is that this isn't the first time I've been bitten by the lack of a comprehensive backup strategy. You'd think I'd have learned by now. Apparently it takes the loss of 15 years worth of sites and work to get me to wake up. the most recent backups I have of some of those sites were...stored on the same drive when I moved them from an older server several months ago. Sigh.

So, the drive shows up in BIOS, but all attempts to read data fail, including SMART data (scsi error: badly formed scsi parameters). This is what dmesg looks like whenever trying to communicate with the drive
data_errors.jpg

Spinrite can't see the drive, and I'm not sure what else I could try. Seems like I'm SOL on any software solution since it's failing at that level. Is this merely a control board that has failed, and I could theoretically find an identical 840 Pro and swap in a control board to get my data? I've done that with a hard drive, all I had to do was carry over the original control board's EEPROM which contained calibratoin data...

Any "freezer" type tricks that work on SSDs?

Thanks <3
 
Last edited:
Start researching data recovery places that can handle SSDs. It's so much more complicated than you're imagining. You can't open it up and swap anything. It's one PCB.
 
The data is probably still there and unaffected on the flash chips, but as was mentioned - this is not a swappy swap deal without doing research first.

Notice the device is only capable of doing: uplink, SATA mode negotiation (UDMA/133) and can maintain a link. But it just keeps responding with zeroes whenever it can.
So it doesn't look like power or cable problem if it happens every time. Try a different SATA controller, or find an ancient computer with SATA I or sata II forced to SATA I.
It looks like a controller i/o problem. We can see after uplink is estasblished DRDY flag is set (drive ready for duty) so it's also not a catastrophic cache failure because it wouldn't have had lit DRDY.
It can't do nothing at all. It doesn't even coherently respond to basic get-capabilities command. It negotiated 'some' connection but the Linux kernel is assuming the rest of the settings like NCQ depth, buffer size and mode... Try a different controller (not just a port), reseat wires, the classic stuff. Let the drive sit idle for a day unpowered. Try it left for a day powered (maybe the onboard controller will reset itself).
Beyond that it's ontrack town or teaching yourself a new skill.
 
Also be aware that some Samsung SSDs store the data on flash chips in encrypted form even if you do not have disk encryption/password set in the computer. The SSD stores the decryption key somewhere and only encrypts that key if you set full disk encryption.

Just be aware that even if you somehow reconstructed the flash memory, don't forget to obtain that decryption key.
 
Back
Top