I just spent 3.5 frustrating hours on the Nvidia support chat, only to be told to come to the forum to make my RMA case.
My DGX Spark is unable to write a single sector to its internal NVMe SSD. The drive passes every self-test it can run, and NVIDIA’s own recovery media cannot restore it. I already have a support case open — 260916-000257 — and completed every diagnostic the agent requested; I was asked to post here for RMA consideration.
System
| Field | Value |
|---|---|
| Product | NVIDIA_DGX_Spark, board P4242 |
| BIOS | AMI 5.36_0ACUM018, 08/06/2025 |
| OS | DGX OS 7.5.0, kernel 6.17.0-1029-nvidia (aarch64) |
| Drive | SAMSUNG MZALC4T0HBL1-00B07, fw NXHB202Q, 4.09 TB, at PCI 0004:01:00.0 |
| Uptime before failure | 42 days continuous |
| Purchased | August 2026, original owner |
What happened
After 42 days of normal operation, a routine 16 KiB log write failed:
nvme0n1: I/O Cmd(0x1) @ LBA 38758168, 32 blocks, I/O Error (sct 0x0 / sc 0x4)
I/O error, dev nvme0n1, sector 38758168 op 0x1:(WRITE) flags 0x9800 phys_seg 4 prio class 2
Aborting journal on device nvme0n1p2-8.
EXT4-fs (nvme0n1p2): Remounting filesystem read-only
Reads continued working normally. On reboot, journal recovery failed on every write, marching sequentially in 40-sector steps — LBA 612360, 612400, 612440, 612480, 612520, 612560, 612600, 612640, 612680, 612720, all sct 0x0 / sc 0x4. Then:
nvme nvme0: Device not ready; aborting reset, CSTS=0x1
fsck.ext4: Input/output error while trying to open /dev/nvme0n1p2
EXT4-fs (nvme0n1p2): unable to read superblock
mount: mounting /dev/nvme0n1p2 on /root failed: Input/output error
After the controller failed its reset, reads stopped too. The unit has not booted since.
Diagnostics completed
The drive reports itself perfectly healthy. SMART captured between the two failures:
critical_warning: 0 media_errors: 0 num_err_log_entries: 0
available_spare: 100% percentage_used: 0% temperature: 43 C
Data Units Written: 3,063,449 (1.57 TB) power_cycles: 33
SMART overall-health self-assessment test result: PASSED
- NVMe Device Self-test, Short / Controller Only — PASSED
- NVMe Device Self-test, Extended / Controller and Namespace — PASSED
- UEFI enumerates the device correctly: 04:01:00:00, vendor 144D, device A810, 4096.8 GB, namespace 1 intact.
- PCIe link at full spec: current_link_speed = 32.0 GT/s PCIe, current_link_width = 4, both equal to max.
- Zero PCIe AER errors on the NVMe function; zero SMMU/IOMMU faults; zero EDAC/MCE events.
- Zero NVMe errors in any previous boot across 42 days.
The official DGX Spark System Recovery could not write to the device. It printed DGX Spark System Recovery Completed, but its own output was:
-- Restore Image
dd: error writing ‘/dev/nvme0n1p2’: Input/output error
1+0 records in
0+0 records out
0 bytes copied, 170.138 s, 0.0 kB/s
e2fsck: Input/output error while trying to open /dev/nvme0n1p2
resize2fs: Input/output error while trying to open /dev/nvme0n1p2
mkdir: can’t create directory ‘/mnt/disk/efi/EFI/’: Input/output error
Zero bytes in 170 seconds, onto a disk it had just formatted. All firmware capsules were skipped as already current (cap version <= esrt version), so there is no firmware remedy available.
Why I believe this is the host-side PCIe path, not the SSD
- sct 0x0 / sc 0x4 is Generic Command Status 04h, Data Transfer Error — a transport/DMA-class fault. Media faults report under SCT 2h; none were seen, and media_errors is 0.
- The failing LBA differs between occurrences, so it is not a bad sector.
- The drive passes both self-tests and reports an empty internal error log, while the host cannot complete a single write. The controller never recorded the failures the host observed.
- Reads worked until the controller reset failed — only then did reads stop.
- I run four other DGX Spark units with the identical drive model and identical firmware (MZALC4T0HBL1-00B07 / NXHB202Q). None has ever logged an NVMe error.
This looks like the same failure as NVMe Write Failures on DGX Spark Founders Edition — same part number, same status code, same read-works/write-fails pattern — which was resolved by RMA and attributed to a PCIe hardware defect in the GPU-NVMe data path.
Request
RMA evaluation, against existing case 260916-000257. Photographs of the initramfs console, the UEFI NVMe configuration page, the self-test results, and the recovery output are all available.
Separately — a recovery-tool defect worth filing
The DGX Spark System Recovery utility reports Recovery Process - Complete / DGX Spark System Recovery Completed and exits Recovery command completed after a run in which dd wrote 0 bytes and every filesystem operation returned EIO. An operator trusting the on-screen result would believe the system had been restored successfully.
