System: DGX Spark, Serial 1983825003705 Driver: 580.159.03 Kernel: 6.17.0-1018-nvidia Firmware: Current (verified via fwupdmgr) Purchase date: March 2026
Summary: Three consecutive boots with kernel space memory translation faults at random addresses. memtester confirms stuck address line. fieldiag passes.
Symptoms:
Random kernel panics under memory pressure (docker build/copy operations)
Random addresses and random fault levels across boots rules out a reproducible software bug.
memtester 110G 10 loops — FAILED:
Stuck Address: testing 0 Skipping to next test... (ALL 10 loops)
FAILURE: possible bad address line at offset 0x0000001196009210
FAILURE: 0xdfffc2187f7f4c53 != 0xdffdc2187f7f4c53 at offset 0x0000000a01b848d0
FAILURE: 0x6e7bab63b3fdf755 != 0x6e7bab43b3fdf755 at offset 0x0000000a01b848d8
(thousands of additional failures)
fieldiag result: PASS (all tests including MemStress in 7m25s)
Question for DGX engineering:
Is the fieldiag MemStress test sufficient to detect a stuck address line defect?
Does memtester failure with stuck address line on a 2-month-old unit qualify for RMA evaluation?
Is there a longer/more exhaustive memory diagnostic available (noted spec_dgx_spark_field_level2.json on the system)?
anis@spark-1:/opt/nvidia/dgx-spark-fieldiag$ # Run only MemStress, continue on error, with full logging
sudo ./partnerdiag --field --test=MemStress --run_on_error
–partner_extra_logging=power,thermal,voltage,clock
Removing Nvidia drivers and services…
Installing MODS driver…
Starting OneDiag…
*
DGX FIELD DIAGNOSTIC *
*
Version r9.257.3
Python /opt/nvidia/dgx-spark-fieldiag/dgx/python/python-3.10.7-glibc-2.17-aarch64/bin/python3
Build Date Thu, 18 Dec 2025
Start time Wed, 20 May 2026 12:37:14
Est. Completion time Wed, 20 May 2026 13:07:14
Logs /opt/nvidia/dgx-spark-fieldiag/dgx/logs-20260520-123701
Inforom logs /opt/nvidia/dgx-spark-fieldiag/dgx/logs-20260520-123701/inforom
Product NVIDIA_DGX_Spark
Product Version A.7
Family DGX Spark
SKU 0000
Serial Number 1983825003705
Testing MemStress OK [ 7:35s ]
Exit Code | Virtual Id | Test | Subtest | Component | Component Id | Notes
Hi @anis.kadri . It’s quite interesting that memtest is failing whereas the fielddiag is not. Field diagnostics specifically bypass OS translation layers. In other words, if memtester is hitting a OS/software-level translation error, it can reflect as a failure in memory.
Can you please provide the full results of the fielddiag test?
As a last resort, a full system restore may resolve the issue, but we would do better to try and see if we can narrow the scope of the issue first. Are there any crashes that are happening regularly?
I did a system restore from a USB stick and it didn’t help. The full fielddiag test is in the ticket I pointed to. I have another spark and don’t have any issues with it.
@anis.kadri are you still running into this issue? If so, please send me privately your fieldiag results, I do not have direct access to your customer support ticket.
I ended up returning it to the store I bought it from and getting a refund because the RMA they initiated was taking way too long (over two months) and I lost my patience.