DGX Spark GB10: partnerdiag PowerStress reproducibly hard-powers-off the box — acpitz 88→97.8°C in 5s, all other field tests pass

I run a DGX Spark as an always-on box for local LLM inference. A couple of weeks ago it
started being off in the mornings — not asleep or hung, powered down, with no reboot and
nothing on screen. It’s happened four times in five days, always inside the window where my
scheduled GPU workload runs, never while idle.

There’s no forensic trace at all: journal stops mid-line, no panic or oops, kdump produces
no vmcore, /sys/fs/pstore is empty, no Xid, no thermal trip. That reads as power loss, not
a crash. So I ran NVIDIA’s field diagnostic to see if I could reproduce it on demand — and
I can, every time, on PowerStress.

Details:::

System
Product NVIDIA_DGX_Spark, Product Version A.7
SBIOS 5.36_0ACUM018
Driver 580.159.03 (open kernel module, aarch64)
Kernel 6.17.0-1021-nvidia
partnerdiag r9.257.8

Everything except PowerStress passes clean

From summary.json — four tests, all Notes: “OK”, error code …000000000000:

┌────────────┬──────────┬────────┐
│ Test │ Duration │ Result │
├────────────┼──────────┼────────┤
│ GpuStress │ 200.1s │ PASS │
├────────────┼──────────┼────────┤
│ C2CStress │ 6.6s │ PASS │
├────────────┼──────────┼────────┤
│ CpuStress1 │ 8.7s │ PASS │
├────────────┼──────────┼────────┤
│ CpuStress2 │ 602.7s │ PASS │
└────────────┴──────────┴────────┘

PowerStress never returns a result — the machine powers off mid-test

This is the finding. PowerStress produces no error code because the box dies before it can
write one. From test_status.log:

{
“name”: “PowerStress”,
“startTime”: “2026-07-18 11:01:41.248446-0700”,
“timeoutInSecs”: 1800,
“testSequenceNum”: 4,
“statusIndex”: 4
}

No endTime, no durationInSecs, no entry in summary.json. Started 11:01:41, machine dead
~11:05 — about 3m20s in.

Reproduced with external instrumentation

Since partnerdiag’s own logging dies with the box, I re-ran PowerStress alone with a 1 Hz
thermal sampler running outside it, writing to disk continuously. Started 13:37:26, dead
13:43:38 — 6m12s. The sampler caught the event (all zones acpitz, °C):

13:43:27 zone0=88.7 zone2=67.5 zone4=85.1 ← stable plateau ~6 min
13:43:30 zone0=88.8 zone2=67.4 zone4=85.6
13:43:31 zone0=88.0 zone2=73.2 zone4=76.5 ← discontinuity
13:43:32 zone0=93.9 zone2=79.5 zone4=69.7
13:43:33 zone0=96.8 zone2=81.9 zone4=69.6
13:43:36 zone0=97.8 zone2=83.6 zone4=70.1 ← +9.8°C in 4s
13:43:38 zone0=96.5 zone2=83.4 zone4=70.2 ← last sample, power gone

zone0/zone5 hold a flat 88.7°C plateau for six minutes, then jump nearly 10°C in four
seconds while zone4 simultaneously collapses from 85.6 to ~70 and stays there. A 9°C rise
in 2s isn’t thermal mass. That looks like either a sensor handoff/miscalibration or a real
unmanaged hotspot that nothing is reacting to.

Ruled out

  • Not software — reproducible on demand with NVIDIA’s own diagnostic, with my entire stack
    stopped and the system in multi-user.target.
  • Not a kernel crash — no vmcore, empty pstore, and a log file left NUL-padded (filesystem
    extended it, data never flushed), which only happens on abrupt power loss.
  • Not thermal throttling working as intended — nothing trips, the box just goes.
  • journalctl --list-boots under-reports the death time (journald is down during the
    isolate); trust the external sampler.

Same signature as several existing reports

Ask

This looks like error class 082-000-1-020000021139 (temperature limits exceeded or thermal
sensor broken/miscalibrated), but I can’t produce that code because the test never
completes. Is that sufficient to open an RMA? Happy to provide the full log bundle, the
sampler CSV, or run any specific test — with the caveat that every PowerStress run is a
hard power-off on a machine I depend on, so I’d rather not repeat it without a reason.

Serial available on request.

Follow-up: updated EC + SoC firmware — box no longer power-cycles, PowerStress now returns 082-000-1-020000600139 (thermal limits / sensor)

Update on the above. Two things changed since the original post, and the second one gives us the error code that was missing.

1. I was two firmware revisions behind on EC and SoC

I hadn’t stated EC firmware in the original post. Checking it, I was behind on the two components most relevant to a thermal fault. Both applied via fwupdmgr capsule-on-disk and verified by version string:

Component Was Now
Embedded Controller 0x03000302 0x03000508
SoC FW (UEFI Device Firmware) 0x0200980f 0x02009b0b

Unchanged, deliberately — one variable at a time, no apt upgrade:

  • SBIOS 5.36_0ACUM018 (did not change; only EC + SoC capsules were staged)
  • Driver 580.159.03 (open kernel module, aarch64)
  • Kernel 6.17.0-1021-nvidia
  • partnerdiag r9.257.8, Product Version A.7

2. Re-ran PowerStress on the new firmware. The box survived — and finally wrote a verdict.

Testing PowerStress ... FAILED [ 8:11s ]

Exit Code         | Virtual Id  | Test       | Component | Notes
MODS-020000600139 | PowerStress | custommods | Power     | Acceptable temperature limits exceeded
                                                          or the thermal sensor is broken or miscalibrated

Final Result: FAIL
Error Code: 082-000-1-020000600139

test_status.log now has a complete record — startTime 23:08:06, endTime 23:16:17, durationInSecs 491.18 — where every previous run had a startTime and nothing else because the box was gone before it could write one.

So the original framing (“PowerStress produces no error code because the machine powers off first”) is superseded. The firmware update stopped the hard power-off. It did not fix the thermal fault — the machine now reaches the same temperatures and trips a limit instead of dying.

Before / after, same test, same box

External 1 Hz acpitz sampler running outside partnerdiag in both runs:

Pre-firmware (13:37) Post-firmware (23:07)
Outcome hard power-off at 6m12s, no verdict FAIL at 8m11s, box stayed up
Peak zone0 / zone5 88.0 → 97.8 °C in 4 s, power loss 2 s later 97.8 °C, sustained ~50 s, then recovered
Sensor behaviour zone2 ↑ 67.4 → 83.9, zone4 ↓ 85.6 → 69.7 zone2 ↓ 81.4 → 65.6, zone4 ↑ 68.0 → 81.4

The same two zones exchange values in both runs. Pre-firmware it happened in the 7 seconds before power loss; post-firmware it happens mid-run with the machine still up. Post-firmware trace:

iso                        zone0  zone1  zone2  zone3  zone4  zone5  zone6
2026-07-18T23:14:19-07:00   97.8   66.8   81.4   66.2   68.0   97.8   67.7
2026-07-18T23:14:20-07:00   97.5   66.8   81.3   66.2   67.9   97.5   67.7
2026-07-18T23:14:21-07:00   97.5   66.2   75.4   65.9   70.7   97.5   67.7   <- swap begins
2026-07-18T23:14:22-07:00   97.4   65.7   69.3   65.8   77.5   97.4   67.7
2026-07-18T23:14:23-07:00   97.6   65.6   66.9   65.8   80.1   97.6   67.7
2026-07-18T23:14:24-07:00   97.7   65.2   65.6   65.8   81.0   97.7   67.7   <- swap complete
2026-07-18T23:14:25-07:00   97.6   65.0   65.4   65.8   81.4   97.6   67.7

zone2 drops 81.4 → 65.6 °C and zone4 rises 68.0 → 81.4 °C over three seconds, while zone0/zone5 sit flat at ~97.6 °C throughout. Two zones trading values in ~3 s with no change in load is not thermal mass — it reads as a sensor handoff or a mapping/calibration problem.

That anomaly survived both firmware capsules, which is what makes me think this is the sensor side rather than the control loop.

Summary

  • All other field tests still pass: GpuStress, C2CStress, CpuStress1, CpuStress2 — MODSErrorCode 000000000000, Notes OK.
  • PowerStress fails reproducibly, now with a clean error code in the 082-000-1- class: 082-000-1-020000600139, “Acceptable temperature limits exceeded or the thermal sensor is broken or miscalibrated.”
  • The failure reproduces on current EC and SoC firmware, so stale firmware is eliminated as a variable.

Is 082-000-1-020000600139 sufficient for an RMA, or do you need 082-000-1-020000021139 specifically? I have the full run tree, summary.json, and both sampler CSVs available. Serial number on request.

Thanks for reporting this. Please first collect and attach the full field diagnostic logs from the failed run, including the logs-*.tgz bundle, test_status.log if present, and the PowerStress/output.log and run.log from the same run.

If the system consistently fails or is unable to complete the field diagnostic, that qualifies for RMA. After collecting the FD logs, please revert here to us for authorization, which will enable you to contact support for an RMA.

If you are able to capture a bit more detail, it would also help to include:

  • sudo journalctl -b -1 > journal_prev_boot.txt

  • sudo journalctl -k -b -1 > kernel_prev_boot.txt

  • nvidia-smi -q > nvidia-smi-q.txt

  • for z in /sys/class/thermal/thermal_zone*; do echo "=== $z ==="; cat $z/type; cat $z/temp; done > thermal_zones.txt

Thanks! RMA approved! Waiting now.

Can you advise what temperatures are normal or safe under load? I’ve had mine power off a few times now, and say 94.6c recently (see What are normal temps under load? Is 94.6c too hot?). I’ve set the GPU clocks to 300-2200 to try and reduce this and things have been better, but I don’t know if I should be concerned.

Yea that looks like it’s too hot. I would run NVIDIA’s field diagnostic they provide and see if it fails. I had Claude code set it up and run for me and keep logs. Before this I saw the dgx run pretty hot. I got a small rack mount on Amazon for dgx and my beelink, attached fans blowing up from bottom to top, so 4 fans total. I still got this power shut off failure after so reported it to Nvidia as others had same problem. My cooling is good, just sensor issue as not do above. Good luck !

I don’t even seem to be able to install the field diagnostics. The instructions at https://nvidia.custhelp.com/app/answers/detail/a_id/5767/~/nvidia-dgx-spark-field-diagnostics result in a duplicate key, and if I resolve that, when trying to install I get this error:

danny@toad:~$ sudo apt install dgx-spark-fieldiag
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 dgx-spark-fieldiag : Depends: ofed-scripts but it is not installable
E: Unable to correct problems, you have held broken packages.

I can’t find any info on others hitting this or how to resolve it.

You may need to disable secure boot in BIOS.

That is in the instructions, but it’s after installing the dgx-spark-fieldiag. Is it likely that secure boot is preventing installation of dgx-spark-fieldiag? (that sounds odd to me, but I don’t know much about it).

It would prevent loading any drivers for sure, and possibly the installation itself.