SATA SSD Data Recovery

AHCI queue depth and FPDMA timeout handling on the bench

AHCI 1.3.1 and SATA 3.2 cap Native Command Queuing at a single 32-entry queue per port. NVMe permits up to 65,535 queues of 65,536 entries each. The practical lab consequence is severe: when a queued FPDMA READ times out on a marginal SATA SSD, the host issues a link reset that aborts every tag in the queue, not just the failing one. 31 healthy reads die alongside one bad LBA.

The failure path is mechanical. The host issues `READ FPDMA QUEUED` (opcode 60h), allocates a tag in the PxSACT register, and waits for the SDB FIS that clears the tag. When a degrading NAND block forces the controller to burn clock cycles on read-retry and ECC recovery, the per-command timeout breaches before the SDB FIS arrives. AHCI error handling has no graceful single-tag abort; it invokes COMRESET, which purges the entire AHCI queue. On a typical Linux host this surfaces in dmesg as `failed command: READ FPDMA QUEUED` followed by `Emask 0x4 (timeout)` and then a chain of resets that take the link down for seconds at a time.

On the PC-3000 SSD bench, the workaround is to remove NCQ from the equation entirely. The imaging session runs synchronously at queue depth 1, with the NCQ feature flag stripped and host timeouts extended past the controller's worst-case read-retry budget. A single bad LBA stalls one read; the next LBA proceeds without losing 31 good reads behind it.

1. Disable NCQ at the bench host so commands serialize at queue depth 1. PC-3000 SSD presents this as a Technological Mode option per controller family.
2. Extend per-command timeouts past the default 5-to-30-second host budget so marginal reads complete instead of triggering COMRESET.
3. Where the controller supports it, route reads through Vendor-Specific Commands on the diagnostic channel rather than the standard AHCI block layer, which bypasses NCQ accounting and PxSACT polling altogether.

SATA controller silicon families and their PC-3000 SSD utility profile

PC-3000 SSD v3.8.10 (Feb 2026) exposes a distinct utility per supported SATA controller family. Each utility carries its own loader, its own Technological Mode entry path, and its own constraints on which silicon revision is fully supported versus partially supported. Naming the utility matters because the loader name on the bench is what tells the technician whether a given drive is in scope before any disassembly happens.

The list below is the supported set per ACELab v3.8.10. Vendors absent from the ACELab matrix are non-supported by definition; we do not claim PC-3000 SSD recovery for them.

Phison (PS3105 / PS3108 / PS3109 / PS3110 / PS3111 / PS3112)

Utility: Phison Active Utility. Technological Mode is reached by shorting the Safe Mode test points on the PCB, after which the utility injects an `SBF*` loader into controller SRAM to rebuild the translator (for example, the `SBFM 71.2` loader is the microcode injected for drives running `SBFK71E0` firmware). Older PS3109 and PS3111 variants are sensitive to the host interface; ACELab mandates a PATA-to-SATA bridge connection rather than a direct SATA port for those families.

Silicon Motion / SMI (SM2236, SM2246EN/XT, SM2256K, SM2258H/G/XT, SM2259XT)

Utility: SM Utility, segregated by OEM rebranding as Crucial-SiliconMotion Utility, ADATA-SiliconMotion Utility, and others. Safe Mode is entered via pin short. The loader carries per-firmware descrambling keys, disables background TRIM and garbage collection while the drive is on the bench, and forces stable single-channel access to the NAND for FTL rebuild.

Marvell (88SS9174 / 88SS9187 / 88SS9189 / 88SS9190 / 88SS1074)

Utility: Marvell VanGogh Active Utility. Technological Mode access is via a diagnostic channel rather than a pin-short Safe Mode. Older unencrypted Marvell silicon permits chip-off and manual FTL reconstruction through the PC-3000 Flash utility; newer iterations bind AES-256 to the controller and require the original controller IC to remain functional for any plaintext recovery to be possible.

Samsung SATA (legacy S3C29 / S4LJ / S4LN families)

Utility: Samsung Active Utility. The PC-3000 module communicates with legacy Samsung silicon through proprietary Vendor-Specific Commands to rebuild translators on supported models including the 470, 830, 840, 840 EVO, 840 Pro, 850 Pro, and OEM CM871 and PM-series drives. Modern Samsung in-house controllers (Polaris, Phoenix, Elpis, MEX, MGX, MHX, MJX, MKX) including the 850 EVO, 860 EVO, and 870 EVO are not in ACELab's supported list; PC-3000 SSD cannot inject a loader for them, so any recovery on those drives is restricted to board-level stabilization plus normal-mode imaging on the original controller. Rossmann does not currently offer in-lab recovery for Samsung MKX, MHX, MJX, MGX, MEX, Polaris, Phoenix, or Elpis controllers.

Maxio (MAS0902 supported; MAS1102 partial)

Utility: Maxio Active Utility. MAS0902 (Lexar DM918 and several rebrands) is fully supported: the utility enters Technological Mode, rebuilds the FTL, and applies XOR descrambling automatically. MAS1102 is marked under deep development by ACELab and is supported only for the 240 GB capacity (ADATA SU650 240 GB). Maxio's NVMe controllers (MAP1602, MAP1602A) are absent from the ACELab matrix; we do not offer PC-3000 SSD recovery for those parts.

Legacy: Indilinx Barefoot, OCZ Barefoot 3, Intel PC29AS21AA0

Indilinx Barefoot Active Utility, OCZ Barefoot 3 module, and Intel Postville Active Utility cover the relevant legacy silicon. These families predate transparent AES-256 in the SATA SSD market, which keeps chip-off plus manual FTL reconstruction on the table when the original controller is electrically beyond repair.

DEVSLP, HIPM, and DIPM as imaging hazards on a marginal SATA SSD

The four SATA power states are defined elsewhere on this page. What matters in an imaging context is that aggressive host-side link power management (ALPM) is the single most common reason a marginal SATA SSD vanishes mid-image. A failing controller cannot meet the 10 microsecond Partial wake budget or the 10 millisecond Slumber wake budget while it is also burning cycles on ECC retry. ALPM must come off before imaging starts.

The dmesg signature is distinctive. A drive that drops out of Slumber or Partial without renegotiating typically logs `ataX: SATA link down (SStatus 1 SControl 300)` followed by `COMRESET failed (errno=-32)` and `reset failed (errno=-32), retrying in 8 secs`. The block device disappears from `/dev/sdX`; any imaging job in flight aborts. On Windows, the storahci driver records Event ID 129 (Reset to device \Device\RaidPortX) and Event ID 153 (IO retried at logical block address) for the same underlying condition. If DEVSLP is the state the drive cannot leave, the OS frequently reports the device as fully disconnected.

1. Disable ALPM at the host. On Linux, write `max_performance` to `/sys/class/scsi_host/hostX/link_power_management_policy` (the only valid libata values are `max_performance`, `medium_power`, `med_power_with_dipm`, and `min_power`). On Windows, set the HIPM and DIPM registry keys for the active power plan to Active (0 ms) so the AHCI driver never requests a low-power transition.
2. Force the SATA PHY to Gen1 (1.5 Gbps) before imaging starts. Marginal controllers and degraded NAND stabilize at the slower signaling rate; signal integrity is no longer the bottleneck during heavy ECC retry passes.
3. Where the drive will not pass identify under standard ATA, enter the controller-family Technological Mode at first power-up. PC-3000 SSD issues vendor-specific commands on the diagnostic channel before any LPM transition is attempted, which sidesteps the entire ALPM negotiation problem.

The takeaway from all three subsections is the same: the SATA protocol stack was designed for healthy drives on a desktop or laptop. A failing SSD breaks the assumptions AHCI was built around: that a queued command will return in bounded time, that LPM transitions will complete, that identify will report a sane capacity. PC-3000 SSD imaging works because it disables every one of those assumptions at the bench before the drive is asked to do anything.

SandForce SF-2281: DuraWrite, RAISE & transparent AES

Rossmann does not currently offer in-lab recovery for SandForce SF-2281.

SandForce SF-2281 is the controller behind Intel 520, OCZ Vertex 3, Kingston HyperX, Corsair Force GT, & a long tail of legacy 2.5-inch SATA drives. The architecture stacks three irreducible layers between host writes & the NAND. First, DuraWrite compresses every host write inline to cut write amplification. Second, RAISE stripes parity across the NAND dies in a RAID 5-style layout to tolerate single-die failure. Third, an always-on transparent block cipher encrypts the compressed, parity-protected payload before it is written to NAND. The cipher was marketed as AES-256; Intel publicly disclosed in 2012 that a silicon-level flaw reduced effective strength to AES-128 on the SF-2281. Either way, the encryption is not optional.

The Media Encryption Key is generated by a hardware random number generator during the drive’s first power-up & fused into the controller die. There is no documented path to extract that key over JTAG, UART, or any vendor diagnostic channel once the silicon is electrically dead. The signature panic state is the BSY 200026BB fallback: the drive identifies asSandForce{200026BB}with a capacity of exactly 32 KB or 0 MB, depending on how far through the shadow bootloader the controller got before it stalled. Consumer recovery software cannot enumerate a logical surface against this signature; the drive presents no usable LBA range.

The SF-1200 / SF-2200 families are absent from ACELab’s PC-3000 SSD supported matrix for that reason. No vendor utility ships for them. Chip-off on an SF-2281 yields compressed, RAISE-striped, AES-128 ciphertext; without the original controller silicon to decrypt inline, the NAND content is mathematically opaque. The only recovery path is board-level revival of the original controller: locating a failed PMIC channel, shorted decoupling capacitor, open voltage regulator, or cracked solder joint with FLIR thermal imaging, & replacing the failed passive on the original PCB with the controller IC still in place. If the SF-2281 die itself has suffered electrical overstress or thermal death, the data is gone. For the broader legacy context see the SandForce & Marvell legacy page.

Marvell 88SS9187 / 88SS9189 BSY state machine

Marvell 88SS9187 / 88SS9189 controllers on Crucial M500, M550, MX100, MX200 & Intel 510 hard-hang in ATA BSY when the Service Area FTL pages degrade past ECC. The PHY links up at 6 Gbps; the controller never clears the Busy bit because firmware initialization never completes. These controller families ARE supported by PC-3000 SSD’s Marvell VanGogh Active Utility through the diagnostic channel, with the caveat ACELab publishes against the model list above: partial support except for BSY-state drives.

The Linux kernel surface is distinctive. After the libata stack drives the COMRESET / COMINIT / COMWAKE handshake successfully, the ATA status register stays locked with the BSY bit asserted. The dmesg sequence reads:

ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata1: link is slow to respond, please be patient (ready=0)
ata1: COMRESET failed (errno=-16)
ata1: hard resetting link

The errno=-16 maps to EBUSY in Linux. On Windows the storahci driver records Event ID 129 (Reset to device \\Device\\RaidPortX) for the same condition. Because the command parser inside the controller never reaches its main loop, standard AHCI vendor-specific commands cannot deliver a loader payload; the parser is not running. Recovery on this family relies on PC-3000 SSD’s Marvell VanGogh Active Utility communicating through a diagnostic channel that bypasses the BSY-locked AHCI register block, which is why ACELab marks the listed Crucial & Intel models partial-supported with the BSY exclusion. The existing Marvell section above documents the chip-off & donor-pairing boundaries for the 88SS1074; the same encryption-binding constraints apply upward to the 88SS9187 & 88SS9189 generations.

Silicon Motion SM2258XT BOOT_SEL mask-ROM entry

Silicon Motion SATA controllers carry a small mask ROM in silicon whose sole job is to bring up the SATA PHY & load Stage 2 firmware from the NAND. When Stage 2 fails ECC, the SM2258XT & SM2259XT typically reboot in a loop or hang in ATA BSY. The recovery entry path is the BOOT_SEL test point: momentarily shorting it to ground during the COMRESET handshake forces the power-on reset logic to sample BOOT_SEL low, abort the NAND boot, & halt in the internal mask ROM. The short must be released within one to two seconds of ROM-mode identification, before the bench injects the LDR payload; a held short blocks the in-system programmer (ISP) transfer.

In this state the controller responds to ATA IDENTIFY DEVICE (opcode 0xEC) with a generic silicon descriptor such asSM2258AB-80-10000000or SM2259XT, paired with a diagnostic capacity of 1 GB (1024 MB) or 0 GB. There is no user LBA range exposed; the mask ROM only carries enough code to accept a loader. One specific correction is worth stating clearly: the SATAFIRM S11 string is NOT a Silicon Motion presentation. SATAFIRM S11 is a hardcoded factory alias inside the Phison PS3111-S11 mask ROM. Conflating the two leads to the wrong loader selection on the bench & wastes power-up cycles.

Once SM2258AB / SM2259XT is on the bench, the SMI Utility (segregated by OEM rebrand: Crucial-SiliconMotion, ADATA-SiliconMotion) selects a microcode loader matched to the silicon revision & NAND flash ID (Micron 3D TLC, Toshiba BiCS, etc.), injects it into the controller’s SRAM through vendor-specific commands, & from there suppresses background garbage collection & TRIM while the FTL is rebuilt. See the dedicated Silicon Motion controllers page for the per-firmware loader notes.

Phison PS3111 R29 & R/B* Safe-Mode entry

The R29 resistor pad on Phison-reference PCBs sits next to vias that connect to the NAND array’s R/B* (Ready / Busy) ONFI line. Shorting that via to ground while cycling the bench power supply forces the controller to read the NAND bus as permanently busy, abort the flash-read sequence, & drop into Phison Technological Mode (Safe Mode).

In ONFI, R/B* is an open-drain active-low signal asserted by a NAND die that is mid-program or mid-erase. The PS3111 BootROM polls this line during its early NAND read; if R/B* never deasserts, the BootROM concludes the flash array is unresponsive & halts in its mask ROM. The drive presents the factory alias SATAFIRM S11 (or SATABURN S11 during a thermal event) with a 0 byte, 2 MB, or 20 MB reported capacity. Windows Disk Management will prompt to initialize the disk; that prompt must be refused. The initialize attempt rewrites partition-table sectors against a drive whose Service Area parameters are corrupted, which compounds the problem.

There is a wider class of consumer-facing tools that surface in search results around SATAFIRM S11: Phison MPTool, PhisonToolBox, & assorted mass-production flashers. None of these are recovery tools. They rebuild the FTL by erasing the NAND, which causes permanent data loss on the drive’s user area. We do not recommend MPTool or PhisonToolBox to end users for any drive containing data the user wants back.

The correct path is PC-3000 SSD’s Phison Active Utility. With the R/B* via held to ground at power-up, the controller enters Technological Mode, the utility injects an SBF*-series loader (for example,SBFM 71.2 for drives running SBFK71E0 firmware) into controller SRAM, & the virtual translator is rebuilt against the NAND OOB tags. See the dedicated Phison controllers page for the full per-firmware loader matrix & the firmware panics & ROM mode page for the cross-vendor mask-ROM model.

PC-3000 Portable III ROM-mode & loader workflow at the SATA layer

Once a SATA controller is in ROM mode by any of the entry mechanisms above, the PC-3000 Portable III workflow over SATA reduces to four discrete steps. Each step depends on direct SATA HBA access; a generic USB-to-SATA adapter strips vendor-specific commands & breaks the loader path entirely.

1. Identify. The bench sends ATA IDENTIFY DEVICE (opcode 0xEC). The response confirms which mask ROM is running: SATAFIRM S11 for Phison PS3111, SM2258AB or SM2259XT for Silicon Motion, & so on. The factory alias dictates which active utility the technician opens next.
2. Loader Select. Inside the active utility (Phison Active Utility, SMI Utility, Marvell VanGogh Active Utility, Samsung Active Utility on legacy S3C29 / S4LJ / S4LN), the technician selects a microcode loader matched to the silicon revision & the NAND flash ID. Phison loaders carry SBF* nomenclature; SMI loaders are keyed to firmware signatures stored in the mask ROM response.
3. VSC microcode injection into controller SRAM. The ATA specification reserves opcodes 0xC0 through 0xFF for vendor-specific commands. PC-3000 SSD carries the loader payload in this range, writing the active utility’s LDR image directly into the controller’s volatile SRAM. A USB-to-SATA bridge implements only the standard ATA opcode subset; VSCs are stripped at the bridge silicon, so the loader never reaches the controller. The PC-3000 SATA HBA must be used directly.
4. Virtual translator rebuild. Once executing from SRAM, the loader suspends background garbage collection & TRIM, granting the bench physical access to the NAND. The utility reads the OOB spare-area tags off every physical page, reverses the XOR scrambling polynomial the controller applied on write, & reconstructs the LBA-to-PBA map in workstation RAM. The recovered logical volume is imaged sector-by-sector to a healthy destination drive.

The NVMe equivalent of this workflow runs over a different transport. On PCIe-attached drives the PC-3000 Portable III acts as the PCIe Root Complex, the loader payload travels in Admin Queue 0 vendor-specific opcodes in the same 0xC0 through 0xFF range, & the controller’s hardware AES engine must be successfully re-initialized as part of loader bring-up because NVMe drives almost universally enforce hardware encryption (unlike the simple XOR scrambling on budget SATA Phison parts). For the NVMe-specific procedure see the NVMe SSD recovery page & the firmware panics & ROM mode cross-vendor depth page. The broader SSD data recovery hub indexes both transports.