Samsung PM9A1/PM9A1a SSDs failing in HP Victus despite HPS3 firmware — can they be recovered?

I have two Samsung OEM NVMe SSDs that have developed what appears to be the same failure in HP Victus laptops, and I’m trying to determine whether either SSD can be recovered.

The drives are:

  • Samsung PM9A1 — 1 TB — firmware originally HPS2NGXK, now/previously updated to HPS3NGXK

  • Samsung PM9A1a — firmware HPS2NGXK / HPS3NGXK situation as well

The PM9A1 is particularly interesting because HP has documented a firmware issue affecting certain PM9A1 drives and recommends updating affected drives to HPS3. I have a PM9A1 that was on HPS2NGXK and had the HPS3NGXK firmware, but it still ended up with the same failure symptoms.

Symptoms

In the HP Victus:

  • The laptop attempts to boot and then fails.

  • The SSD is subsequently reported as non-functional / unavailable.

  • When I remove the SSD and put it into a HIKSEMI USB NVMe enclosure using a Realtek RTL9210 bridge, Linux detects the enclosure, but not the actual NVMe SSD.

Linux reports:

sdb  0B  HIKSEMI  012345684681  disk

nvme list doesn’t detect an NVMe device at all.

blockdev --getsize64 /dev/sdb returns:

0

smartctl cannot communicate with the drive.

The kernel reports:

Read Capacity(10) failed
Sense Key : Illegal Request
Add. Sense: Invalid command operation code
0 logical blocks
0-byte physical blocks

The USB enclosure itself is correctly detected as:

Realtek Semiconductor Corp. RTL9210 M.2 NVME Adapter

so the USB-to-NVMe bridge is at least responding.

I have also tested the PM9A1a, and it produces essentially the same 0-B behaviour through the enclosure.

What I’m trying to determine

  1. Does this behaviour indicate a dead NVMe controller, or could the SSD still be recoverable?

  2. Has anyone successfully recovered a PM9A1 in this state?

  3. Is there a way to communicate directly with the SSD/controller through Linux despite it appearing as 0 B through the RTL9210 enclosure?

  4. Could this be related to the known PM9A1 firmware issue even when the PM9A1 has already been updated to HPS3NGXK?

  5. Is there any safe diagnostic procedure I can perform before putting the SSD back into a laptop’s internal M.2 slot?

  6. If the data is important, is there anything I should not do that could make recovery more difficult?

I am deliberately avoiding destructive operations such as formatting, partitioning, secure erase, or firmware flashing until I understand the current state of the SSD.

I’m particularly interested in answers from anyone who has encountered PM9A1/PM9A1a + HP Victus + 0-B/unrecognized NVMe failures and managed to recover the drive or the data.

HP’s documentation about the PM9A1 firmware issue is here:

HP PM9A1 firmware issue / HPS3 documentation