Samsung 860 EVO 1TB all sector reads time out - DEEP DIVE

[HannsGruber]

I’ve been working on a failed Samsung 860 EVO 1TB and figured I’d document what I’ve found so far before I go any farther with it.

Drive is..
Samsung 860 EVO 1TB
Model: MZ-76E1T0
Firmware: RVT02B6Q
Label date: 2019.04

Controller is Samsung MJX / S4LR030, DRAM is K4F8E164HM-BGCJ, and there are two K90UGY8J5M NAND packages, one on each side of the PCB.

The failure was pretty abrupt. This drive was normally left powered basically 24/7. The computer was fully functional, withstood daily reboots, no SMART errors just a week prior. It was shut down and left off for around a week while I went on vacation, and after that it would no longer boot normally. The motherboard would hang at the ASUS splash screen with the green BOOT LED.

The drive can still identify correctly, but I have never gotten a valid sector back from it since the failure.

I do have the BitLocker recovery key, but obviously that doesn’t matter until I can get raw sectors off the thing.

I originally tried the usual software-side stuff and then sent it to $300 Data Recovery. They were also unable to recover it and suggested a deeper lab.

I’ve since been doing board-level diagnostics myself.

With SystemRescue and the SATA link forced down to 1.5 Gbps, NCQ disabled, etc., Linux will eventually expose /dev/sda.

Kernel options I’m currently using are:

Code:

libata.force=6:1.5G,6.00:noncq,6.00:nologdir,6.00:noiddevlog,6.00:nodmalog,6.00:nosetxfer

The drive identifies completely and coherently.

hdparm -I /dev/sda gives:

Code:

Model: Samsung SSD 860 EVO 1TB
Firmware: RVT02B6Q
LBA sectors: 1,953,525,168
Logical/physical sector size: 512 bytes
SMART supported/enabled
Security not enabled / not locked
Checksum: correct

IDENTIFY is basically instant. With smartctl ioctl debugging I see IDENTIFY completing in approximately 0.0002 seconds.

Anything that actually needs the media side of the drive is a different story.

A typical read results in:

Code:

Emask 0x4 (timeout)
status: { DRDY }

The SATA link then gets reset, comes back at 1.5 Gbps, and the drive identifies again.

ddrescue forward and reverse both recovered 0 bytes.

I have also tried ordinary reads, DMA reads, and previously forced PIO/READ MULTIPLE. No valid user sector has ever been returned.

SMART is interesting though.

Code:

smartctl -A /dev/sda
smartctl -H /dev/sda

both fail.

However, with:

Code:

smartctl -r ioctl,2 -A /dev/sda

the initial IDENTIFY completes immediately, but SMART READ ATTRIBUTE VALUES (0xB0 / feature 0xD0) sits there for about 60 seconds before failing with an aborted command.

SMART STATUS CHECK behaves essentially the same way, about 60 seconds before aborting.

So these don’t appear to be immediate unsupported-command rejects. The drive accepts the operation and then disappears into something internally until the host gives up.


Power / board measurements
I’m powering the SSD independently from a bench supply using only SATA +5 V and ground. SATA 12 V and 3.3 V are not connected.

Normal current is roughly 0.20–0.22 A at 5 V.

The drive itself generates all of its internal rails, including a ~12.08 V boost rail.

The PMIC is a Samsung S2FPS05A01.

I checked the large inductors around it for shorts first. None of the outputs look shorted.

Measured live rails at the PMIC area are:

Code:

1.8 V
2.5 V
0.8 V
4.9 V
0.8 V
1.8 V
1.1 V

All of those remain stable during failed read attempts.

I also scoped the output side of the 0.8, 1.1, 1.8 and 2.5 V rails and did not see any obvious AC or DC ripple, collapse, or dropout when the drive hangs.

The switch node side of the buck inductors looks like normal switching activity.

Thermally, after running for a while:

Code:

MJX controller: ~125–130°F
PMIC/power area: ~106–120°F
NAND packages: essentially ambient

I haven’t found any tiny passive getting abnormally hot.

The NAND areas on both sides of the PCB are also remarkably symmetrical electrically.

I mapped the local voltages around both packages. Between the two sides I have matching rails at approximately:

Code:

2.5 V
1.2 V
1.8 V
3.3 V
12.08 V
~0.5–0.6 V nodes
0 V / ground-reference nodes

Resistance-to-ground measurements between equivalent points around NAND A and NAND B are also very close.

Examples:

Code:

2.5 V pair: both ~156 kΩ
1.2 V pair: 4.5 kΩ / 4.3 kΩ
1.8 V pair: 45 kΩ / 49 kΩ
3.3 V pair: both ~145 kΩ
~0.6 V pair: both ~3.4 kΩ
0 V nodes: both ~300 Ω

The 12 V nodes are both very high resistance to ground, around the megohm range.

So at least from a gross board level perspective, I don’t see one NAND package with a missing supply or a hard short.

DRAM area
The DRAM is the Samsung LPDDR4 package mentioned above.

Around that area I measured:

Code:

1.8 V
2.5 V
0.8 V
1.20 V
12.08 V

The 1.20 V rail is very stable and occasionally reads 1.21 V on the meter.

I also checked the DRAM-area rails during an actual failed sector read. The 1.8 V and 1.20 V rails remain solid while the command is hanging.

One interesting topology detail: there are two separate 1.8 V nodes near the DRAM area.

One measures roughly 40–45 kΩ to ground, the other roughly 538 kΩ to ground, and there is about 510 kΩ between the two, so they are clearly not the same 1.8 V net.

I have also been cross-referencing the PCB against the 860 EVO boardview image published by Lardman (with USBRecovery...) It appears to be literally the same board layout as the drive on my bench, and I’ve been able to start matching my temporary test-point labels to actual component designators.

Current behavior
With SATA disconnected and only +5 V applied, current initially sits around:

Code:

0.204 A

During one long power-only test I logged:

Code:

02:39 AM   0.204 A
02:51 AM   0.221 A
04:18 AM   0.225 A
02:14 PM   0.204 A

So there was some kind of temporary internal state/current change, but after about 11 or 12 hours of uninterrupted power it was back at the original ~0.204 A.

When SATA was connected again it rose to roughly:

Code:

0.215 A

but reads still timed out.

I found the HDDGuru threads where people have reported 860 EVOs coming back after being left powered for many hours and then rebooting the host.

So, I also tried leaving the SSD continuously powered from the bench supply while rebooting/resetting the PC several times. The SSD never lost +5 V during this.

Each reboot causes visible changes in the current draw as the drive partially initializes, but it always ends up in exactly the same state: IDENTIFY works, Linux eventually sees the device, and anything involving actual media access hangs.

I’m now also trying extended idle periods with SATA connected, because I’m not sure whether whatever background recovery/maintenance routine these drives sometimes perform requires a live SATA link.

Where I’m currently at
At this point I’m fairly confident this is not a simple missing power rail or hard short failure.

The SATA/ATA-facing portion of the MJX is clearly alive. It can return a completely coherent IDENTIFY DEVICE structure with a valid checksum essentially instantly.

The failure seems to happen deeper inside the controller when it tries to do something involving NAND/FTL/system metadata.

My current suspects are something along the lines of:

MJX unable to initialize or reconstruct FTL/system area metadata
controller to NAND communication/channel problem
partial failure inside the MJX media side while SATA/front end still works
DRAM or MJX<->DRAM interface issue
NAND system area corruption rather than a simple NAND power failure

What I’d really like to know from anyone who has dealt with a lot of these is.... is this a known 860 EVO / MJX failure pattern?

Specifically, the combination of:
perfect IDENTIFY + valid checksum + DRDY + all actual reads/SMART commands hanging for ~60 seconds

seems pretty specific.

Also, if anyone familiar with the 860 EVO boardview knows which MJX support signals are worth checking next, like reset, clocks, enables, power good signals, etc. I’d appreciate some direction (I'll slip you a benjamin Lardman if you can get me some schematics )

I’m avoiding blind reflow, NAND removal, controller reballing, random voltage injection, firmware updates, SMART self-tests, secure erase, etc. because, well, I'm not equipped to reflow unless it's in my kitchen oven.

I have microscope photos, thermal images, annotated NAND/DRAM voltage maps, oscilloscope captures, and the current measurements above if any of those would be useful.

Sorry for the long post, but with so few published case studies on these 860 drives, I figured someone on google might appreciate this in 5 years.

[HannsGruber]

Reverse ddrescue test against the final 128 LBAs of the disk: 0/65536 bytes recovered, one read error after 3m 36s. No valid data returned from the end of the address space either.

[fzabkar]

I have the same SSD. Mine has gone AWOL about 20 times. Each time I managed to recover it by disconnecting the SATA data cable and allowing the drive to remain powered for several hours. On the last occasion I powered it for over one day. The idea is that the SSD repairs itself during that time. I believe that the Flash Translation Layer (FTL) becomes corrupt.

After the SSD comes back, I run Puran's DiskFresh against it. This reads and rewrites every sector. The penalty is one P/E cycle or two.

[HannsGruber]

I have the same SSD. Mine has gone AWOL about 20 times. Each time I managed to recover it by disconnecting the SATA data cable and allowing the drive to remain powered for several hours. On the last occasion I powered it for over one day. The idea is that the SSD repairs itself during that time. I believe that the Flash Translation Layer (FTL) becomes corrupt.

After the SSD comes back, I run Puran's DiskFresh against it. This reads and rewrites every sector. The penalty is one P/E cycle or two.

I saw your earlier posts while searching the forum. I left it powered on the benchtop supply for 12 hours, then connected SATA and tried to initialize it. Can you document the reproducible steps? is it..

PC ON, SSD connected to PC PSU without SATA
Wait xxx hours
Reconnect SATA
Reboot PC?

Do you generally just hit the reset switch, or do you do a full power down cycle on the SSD? My pile of straws is getting thin, so I'm grasping at any that I can find lol

[fzabkar]

I usually power cycle the SSD. I also recall a Youtube video where someone recovered 4 (?) of the same model which he purchased as a non-working batch.

https://www.youtube.com/watch?v=NH9tGrKl5-c

[michael chiklis]

Yep, i shared the power trick for this samsung ssd 1 year ago
https://forum.hddguru.com/viewtopic.php?f=10&t=45442

[HannsGruber]

I've tried a few hours, 12 hour, 24 hour, and 36 hour intervals. None have produced any alternative results to the problem.

[michael chiklis]

I've tried a few hours, 12 hour, 24 hour, and 36 hour intervals. None have produced any alternative results to the problem.

Probably because you haven't solved yet the issue that caused your ssd to not be detected.
What i've found is that samsung ssd are very sensitive to not stable power supply and motherboard thermal throttle.
Solve the initial problem first!
Try with a new power supply and new cables and change CPU thermal paste if is very dry (usually it needs to be changed every 4 years al teast).
In alternative, try on another computer!

Keep your ssd powered on (only the power, NO data cable) for some hours, then power it off.
At next power cycle you can try to connect data cable to the ssd, if still doesn't work try again the procedure for other 3 or 4 times.

PC ON, SSD connected to PC PSU without SATA
Wait xxx hours
POWER OFF SSD (or the PC).
*KEEP SSD OFF FOR A WHILE*
POWER IT ON AGAIN and wait until complete OS boot
Reconnect DATA cable
"DOES IT WORK" ?

If it works then great!
If not, repower ssd without data cable and repeat the process other 3 or 4 times.

*
In my case it didn't work if i repowered after few minutes/hours.
It did work after i tried about 3 times at distance of months.
Probably this didn't make any difference, in my opinion what made the difference in my case was obstinacy on repeating the procedure + fixing the computer issue.

[HannsGruber]

I've tried a few hours, 12 hour, 24 hour, and 36 hour intervals. None have produced any alternative results to the problem.

Probably because you haven't solved yet the issue that caused your ssd to not be detected.
What i've found is that samsung ssd are very sensitive to not stable power supply and motherboard thermal throttle.
Solve the initial problem first!
Try with a new power supply and new cables and change CPU thermal paste if is very dry (usually it needs to be changed every 4 years al teast).
In alternative, try on another computer!

Keep your ssd powered on (only the power, NO data cable) for some hours, then power it off.
At next power cycle you can try to connect data cable to the ssd, if still doesn't work try again the procedure for other 3 or 4 times.

PC ON, SSD connected to PC PSU without SATA
Wait xxx hours
POWER OFF SSD (or the PC).
*KEEP SSD OFF FOR A WHILE*
POWER IT ON AGAIN and wait until complete OS boot
Reconnect DATA cable
"DOES IT WORK" ?

If it works then great!
If not, repower ssd without data cable and repeat the process other 3 or 4 times.

*
In my case it didn't work if i repowered after few minutes/hours.
It did work after i tried about 3 times at distance of months.
Probably this didn't make any difference, in my opinion what made the difference in my case was obstinacy on repeating the procedure + fixing the computer issue.

Thank you for the data. I did try the PC PSU and a bench top lab power supply during my experimentation. I can actually detect the SSD, just not from within windows. I can communicate to it through SATA 1.5g on Linux, and just basic firmware prodding. I'll keep trying various power cycling methods.

[HannsGruber]

michael chiklis, do you have the RVT02B6Q firmware in your database, perchance? It appears to require a password.

[Lardman]

I’d appreciate some direction (I'll slip you a benjamin Lardman if you can get me some schematics )

You've already gone beyond anything that could be gained from what I produced.

You need to get eyes on what's actually happening, get some terminal output. From what I've read of your very comprehensive post (excellent job BTW) I don't expect this to be a board level problem.

[ora]

It appears to require a password

The link in the signature is missing the decryption key; the full link is below, but it contains files only for standard hard drives, not for SSDs.

https://mega.nz/folder/O01DkBRI#MxP2J6ZNqXDcrX40I8MoQQ

[michael chiklis]

michael chiklis, do you have the RVT02B6Q firmware in your database, perchance? It appears to require a password.

No i haven't.
MRT and even PC3000 are uncapable to dump fw modules of this drive.

If your ssd is detected then you've a different issue than what i had on my 860 evo.

[HannsGruber]

Shenanigans are afoot.

[saltwater]

Shenanigans are afoot.

What is this magic for? What we see on this picture?

BTW i have an exact same case as yours. Same drive , same behavior

20260928_184754.jpg

[michael chiklis]

The picture doesn't mean nothing, just pretending doing reverse engineering.
Neither AceLab has't found yet a solution to "hack" 860 evo fw

[Lardman]

Neither AceLab has't found yet a solution to "hack" 860 evo fw

In all fairness Ace are interested in commercially viable solutions not specific case recoveries, that doesn't mean that individual, isolated faults are always unsolvable. The issues with sandforce controllers for example. I got my arse handed to me on a plate when I tried, but someone will get there eventually.

[michael chiklis]

Samsung 860 Evo have been among the most widespread and widely used SATA SSDs (at least in my area).
I don't think Ace wasn't interested in finding a solution; they simply couldn't unlock them, and now they have little interest in devoting time to it (the focus today is on newer models), given that the 860 Evo is now too outdated (and fewer and fewer people own one).

[gold6565]

I found a firmware file I had—I was interested in it at one point, but after looking at the contents, I lost interest. I didn't even finish reading it through.

Attachments

RVT04.7z

(932.27 KiB) Downloaded 74 times

[HannsGruber]

The picture doesn't mean nothing, just pretending doing reverse engineering.
Neither AceLab has't found yet a solution to "hack" 860 evo fw

I mean, I definitely haven't "solved" the controller, but pretending is a bit much lol.
The TAP is alive and the controller exposes a normal ARM JTAG-DP. AP1 identifies as an ARM APB2/APB3 MEM-AP, with a valid CoreSight-style ROM table at 0x80000000. That table advertises six downstream components at roughly +0x20000, +0x40000, +0x60000, +0x80000, +0xA0000 and +0xC0000.
I've mapped a good chunk of that space now. Two 128kb regions return 0xEAFFFFFE at every aligned word, but controlled writes showed they aren't really 128KB of RAM. They behave like four writable 32-bit slots mirrored every 0x10 bytes. Another 4kb component at +0xC0000 is completely mapped and repeats a 0x20070727, 0x00000001 register-looking pair every 0x100 bytes. The areas around these components fault cleanly, while the three middle ROM entries are mostly WAIT-prone and still unexplored.
The stranger part is that the whole observable map repeats every 1MB. I tested addresses all the way from 0x00000000 to 0xFFFxxxxx and the same ROM entries, values, and even the same fault locations keep reappearing. I also verified that the AP really is receiving and storing the full 32-bit TAR address, so it isn't my software accidentally masking it to 20 bits. The best documented match so far is a normal ARM APB-AP feeding a narrower CoreSight debug interconnect, tho I can't yet tell whether that's just ordinary address decoding or something Samsung added downstream.
So at this point I'm thinking this 1MB space may basically be the controller's debug toolbox rather than its normal memory map. The interesting question now is what the six advertised tools actually are, especially the three that currently WAIT, and whether one of them provides the bridge into the real CPU/system memory.
I haven't read user data, firmware or nand through JTAG yet, so I'm not claiming anything ridiculous, but I'm definitely not pretending.