DGX Spark fans stop when the screen goes dark or running from SSH — box gets too hot to touch* FIRE HAZARD

Accelerated Computing DGX Spark / GB10 User Forum DGX Spark / GB10
1

I’ve got a fan problem on my DGX Spark and after talking with they support asked me to post it here.

If I’m logged into the desktop with a monitor hooked up and the screen blanks after sitting idle, the fans shut off about a minute later. Wiggle the mouse, screen comes back, fans come back. Happens every single time.

Same deal running headless. The fans never turn on at all, and the case gets so hot I can’t keep my hand on it, with nothing running. Use the video switcher and wiggle the mouse, and everything works normal and cool.

While it’s hot, nvidia-smi shows the GPU idle at P8, 3W, 0% util. htop shows nothing running. Temps just climb and the fans never respond. GDM is up and running the whole time. Everything is current, apt packages, firmware, EC, all of it ..

This unit a only a few days old and i did not have this problem out of the box only with the last update did i notice it.

This looks like the same thing reported other threads. I can reproduce it on demand, both ways, and I’m happy to pull whatever logs you need.

Fans should run off the thermal sensors, not the display. Is this a known issue, and is a firmware fix coming? And is there a safe way to run this thing headless in the meantime?

2

I would try running the field diagnostics - see posts from Spark abruptly shuts down - #9 by aniculescu

If they fail (as mine has), it should be replaced.

3

Thank you for reporting this @dmayer1 — a device that becomes too hot to touch is a genuine safety concern and we want to make sure we’re understanding as much as we can immediately about this issue in order to manage it. Here’s what we need to move forward in an expedited way:

Step 1 — Run field diagnostics

Please run the DGX field diagnostics and share the output here. Success or failure will confirm a baseline hardware state which is useful in diagnosing this issue in any case, even if we suspect the root cause to originate from software/firmware layers.

PS: Thanks @DannyTup for providing the relevant post/link above!

Step 2 — Capture state during the fault

Since this is reproducible on demand and your original post suggested you have monitor/keyboard direct access as well as SSH access, you can capture the system at the exact moment fans have stopped — without waking the display. From a local terminal, force the screen off:

xset dpms force off

Then wait ~60 seconds, switch to SSH without touching the display, and run:

echo "=== fault-state capture ===" ;
nvidia-smi -q -d TEMPERATURE,FAN,POWER ;
find /sys/class/hwmon -name 'fan*_input' 2>/dev/null |
  xargs -I{} sh -c 'echo {}; cat {}' ;
for z in /sys/class/thermal/thermal_zone*/; do
  printf "%s\t%s\n" "$(cat ${z}type 2>/dev/null)" "$(cat ${z}temp 2>/dev/null)"
done ;
sudo journalctl --since "5 minutes ago" |
  grep -iE 'fan|thermal|temp|pwm|cool|dpms|blank|idle' ;
sudo dmesg | grep -iE 'fan|thermal|temp|pwm|cool|throttl' | tail -30

This captures GPU temperature and fan % from nvidia-smi, raw fan RPM from the hwmon kernel interface, per-zone thermal readings with their labels, and any kernel/systemd log activity that coincides with the fans stopping.

Step 3 — Additional baseline system information

Please also collect the following at any time (normal operating state is fine):

# OS, kernel, and firmware
cat /etc/dgx-release 2>/dev/null || cat /etc/os-release
uname -r
sudo dmidecode -t bios | grep -E 'Version|Release'
sudo dmidecode -t system | grep -i serial

# Identify the triggering update
grep -A5 -B1 -i 'nvidia\|dgx' /var/log/apt/history.log | tail -80

# Installed NVIDIA packages
dpkg -l '*nvidia*' | grep '^ii'

# Full GPU status (normal state)
nvidia-smi -q

# Fan and thermal sysfs layout
find /sys \( -name 'fan*' -o -name 'pwm*' \) 2>/dev/null | grep -v proc | head -40

# NVSM health if available
sudo nvsm show health 2>/dev/null || echo "nvsm not available"

We’re working with our engineering teams on this critical concern. We appreciate your assistance in providing the requested information above; this will help us take action quickly.

~~ Neill

7
8

Neill, I captured the fault live. I was connected over SSH with the display blanked and the chassis too hot to touch, fans not spinning. Ran your Step 2 capture without waking the display:

=== fault-state capture Mon Aug 3 11:52:42 PM UTC 2026 ===
GPU Current Temp    : 52 C
GPU T.Limit Temp    : 43 C
Average Power Draw  : 3.72 W
--- thermal zones ---
acpitz  55700
acpitz  52800
acpitz  52700
acpitz  52800
acpitz  52800
acpitz  55700
acpitz  53700
--- fan inputs ---   (empty — no fans reporting RPM)
--- recent journal ---   (no thermal/fan/dpms entries)

Key points:

  • GPU is 9C above its T.Limit target (52C vs 43C) while pulling only 3.72W. Idle, but running hot.
  • All thermal zones sitting at 52-56C and rising. For reference, with the display awake and fans running earlier today these same zones read 45-49C.
  • No fan RPM is exposed via hwmon in this state at all — the fans simply aren’t spinning.
  • Nothing in the journal about thermal/fan/dpms events, so the fan controller isn’t logging or reacting to the rising temps.

Trigger confirmed: this happens when the display powers off (DPMS off). Running xset dpms force off reproduces it on demand, and waking the display spins the fans back up within seconds and temps start dropping. It also happens on a headless boot with no display detected at all.

The field diagnostic I sent to the case passed all thermal, power, GPU, CPU, memory, and SSD tests under full load, so the cooling hardware is healthy. The fans only fail to engage based on display state, which points to firmware/EC logic rather than hardware.

Happy to pull anything else you need… BTW the temperature is rising … this is just after 5 min of sitting here

9

I’ve seen this a few times on new machines doing fresh upgrades after initial OOBE, downgrading the EC firmware helps. If you connect the CX7 NIC you can then upgrade to the latest EC firmware and it will work as expected. Very concerning.

Brand new machines will sit there fully updated while idle and the fans will not spin up, while the unit gets wildly hot to the touch.

10

tonight sitting here idle here is the temp reading … is this a RMA issue now ?

~$ paste <(cat /sys/class/thermal/thermal_zone*/type) <(cat /sys/class/thermal/thermal_zone*/temp)
acpitz 55800
acpitz 52900
acpitz 52900
acpitz 52800
acpitz 52800
acpitz 55800
acpitz 54700

11

Looks like I’ve got this issue too on a second (brand new) Asus GX10. Both EC versions (0x02000005 and 0x02000006) have the same behavior.

The idle unit heats up to 51-53C without doing anything - headless with only an SSH connection. Then connecting via VNC to the unit’s X session kicks the fan a bit and the temperature goes down, reaching 44-45C.

The first GX10 unit stays at 36C in the meantime without any extra actions (also headless). But this unit didn’t have any updates for about 2 months.

It’s weird but it looks like the device needs some activity to have the fan going.

12

I’ve attached fwupdmgr_get-history output for both device (cold and hot).

GOOD_device_fwupdmgr_get-history.txt (4.6 KB)

BAD_device_fwupdmgr_get-history.txt (5.5 KB)

13

I tend to think it’s a software/firmware problem. What I noticed:

  • booting the device to idle - the temperature keeps increasing, reaching 53C (GPU), sometimes even more. At the same time thermal_zone1 (“SOC”) shows +56.7°C.
  • connecting via VNC, launching DGX dashboard and keeping it open - the device starts to cool down, slowly reaching 40C GPU / +43.8°C SOC.

I use this command to pull temperature readings from all sources (nvidia-smi, sensors and ACPI thermal zones):

@dgx-spark2:~$ echo && nvidia-smi | grep "Not Supported" && echo && sensors && paste <(cat /sys/class/thermal/thermal_zone*/device/path) <(cat /sys/class/thermal/thermal_zone*/temp)

| N/A   40C    P8              2W /  N/A  | Not Supported          |      0%      Default |

mt7925_phy0-pci-90100
Adapter: PCI adapter
temp1:        +43.0°C  

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +43.5°C  
temp2:        +41.5°C  
temp3:        +41.5°C  
temp4:        +41.6°C  
temp5:        +41.5°C  
temp6:        +43.5°C  
temp7:        +41.4°C  

nvme-pci-40100
Adapter: PCI adapter
Composite:    +41.9°C  (low  =  -5.2°C, high = +82.8°C)
                       (crit = +84.8°C)
Sensor 1:     +42.9°C  (low  = -273.1°C, high = +65261.8°C)

\_TZ_.TSOC      43500
\_TZ_.TS0E      41400
\_TZ_.TS0P      41500
\_TZ_.TS1E      41600
\_TZ_.TS1P      41500
\_TZ_.TGPU      43500
\_TZ_.TUNC      41400
14

Hi @Dmayer, @Sebastian_Jug, @X1917x — thank you all for the detailed reports, cross-unit comparisons, and for sharing the diagnostic log @Dmayer.

@Dmayer — your unit needs to go to RMA. The field diagnostic log shows a CX7Stress failure (“Unable to start MST”), and a failed diagnostic means the unit should be replaced. Please open an RMA case with NVIDIA support if you haven’t already. One additional note: the CX7 failure may also block the EC firmware downgrade workaround since that process requires CX7 NIC connectivity — so the downgrade path likely isn’t available to you on this unit.

For @Sebastian_Jug and @X1917x and anyone else seeing this issue without a diagnostic failure, the interim workarounds while we investigate are:

Disable DPMS sleep — keep the display active (xset -dpms or via system power settings)
VNC virtual display — as @X1917x noted, a VNC connection creates a virtual framebuffer that restores fan operation
EC firmware downgrade — @Sebastian_Jug confirmed this resolves it; requires CX7 NIC connectivity for the update
We have this tracked internally and are investigating the EC firmware behavior change. A couple of data requests that would help:

@X1917x — do you know the exact EC firmware version your unaffected unit is running?
Does anyone have output from a sysfs hwmon fan path (e.g. /sys/class/hwmon/hwmon*/fan*_input) in both the fault state and healthy state? nvidia-smi reports N/A for fan speed on this platform regardless, so we need a readout that actually reaches the EC.
We’ll update this thread as we have more to share.

15

The unaffected (cold) unit has EC firmware 0x02000005:

│ └─GX10 Embedded Controller Update:
│       New version:      0x02000005
│       Remote ID:        lvfs
│       Release ID:       139357
│       Summary:          GX10 Embedded Controller Firmware Update
│       License:          Proprietary
│       Size:             518,9 kB
│       Created:          2026-04-08
│       Urgency:          High
│       Vendor:           Asus
│       Duration:         30 seconds
│       Release Flags:    • Trusted metadata
│       Description:      
│       This update improves the performance and stability of the Device.
│       
│       • OTA2.2 EC hotfix release.
│       Checksum:         56023de68779af3b1696dc6c216af99dfd771abb99d1ad4abd2bb494c1098c0e

The hot one has a newer version - 0x02000006, but I tried downgrade to 0x02000005 and it didn’t resolve the issue, so EC firmware might be not related… at least in my case.

I see one extra difference between these two devices:

Cold one:

| NVIDIA-SMI 580.159.03             Driver Version: 580.159.03     CUDA Version: 13.0     |
+-----------------------------------------+------------------------+----------------------+
| N/A   36C    P8              5W /  N/A  | Not Supported          |      0%      Default |

=> the device always has 5W power minimum after booting, I never saw it showing 3W or 2W. Note that the NVIDIA driver version is 580.159.03 here.

Hot one:

| NVIDIA-SMI 580.173.02             Driver Version: 580.173.02     CUDA Version: 13.0     |
+-----------------------------------------+------------------------+----------------------+
| N/A   44C    P8              3W /  N/A  | Not Supported          |      0%      Default |

| NVIDIA-SMI 580.173.02             Driver Version: 580.173.02     CUDA Version: 13.0     |
+-----------------------------------------+------------------------+----------------------+
| N/A   43C    P8              2W /  N/A  | Not Supported          |      0%      Default |

| NVIDIA-SMI 580.173.02             Driver Version: 580.173.02     CUDA Version: 13.0     |
+-----------------------------------------+------------------------+----------------------+
| N/A   51C    P8              3W /  N/A  | Not Supported          |      0%      Default |

=> it has newer driver version, 580.173.02 and has 2W and 3W power as the minimum.

More observation:

  • tried ping’ing the hot device non-stop without connecting a VNC session (just to check if having a Dashboard-like periodic activity helps) - doesn’t help, the device is hot

  • instead of running DGX Dashboard in the VNC session left the System Monitor app running instead (open on Resources tab) - helps, the device gets cold

  • but once VNC session got locked out (was set to 15 minutes in my case) - the device started to heat up again

16

Yet more observations…

  • for VNC it’s not enough to just have the session window open, it must have an app running (like System Monitor or DGX Dashboard), otherwise the device heats up. With an app running in a VNC session the device gets/keeps cold

  • for a connected monitor this is not required - just having an empty desktop (static image) without moving the mouse or any programs running is enough for the fan to work and have a low temperature. In fact, this gives the best results so far - finally GPU temp can drop even below 40C

  • testing the “hot” device with real heavy load (parallel client threads with many inference requests non-stop, a lot of both prefill and decode) passed without any crashes or switching off and produced results similar to the “cold” GX10 unit - both were having temps around 75C (GPU) under load, with the “hot” device reaching 77-78C sometimes. The fan was very noticeable (but not noisy), I didn’t see any throttling. Ambient temperature is relatively high BTW - 26-28C.

  • also, the malfunctioning “hot” device successfully passes the dgx-spark-fieldiag test (except CX7Stress which I guess is fine without the cable). Ironically, during stress tests the unit was colder than sometimes while being idle

  • the weird part happened right after disconnecting monitor/keyboard and rebooting after field-diag. Suddenly all workarounds to cool down the device stopped working completely. Neither running anything in a VNC session or connecting the monitor produced any effect, the fan was completely unnoticeable. And the device started to heat up like crazy - before it was climbing up to 53C and then staying at this point, but in this new weird state it lost any control - GPU reached temps around 65C with tempzone1/6 around 70C (completely idle device!) when I powered the device off, unplugged the cord and turned on again - this helped, both VNC/monitor workarounds started to work again and were keeping the fan working and the device finally cooled down quickly.

The last situation was really scary - the device was extremely hot on the sides, probably even higher than 70C. When it finally turned on the fan it even had some kind of hot metal smell.

So the main conclusion is that the affected device doesn’t have thermal issues under real load or stress tests but overheats badly when idle.

20260808_022117
20260808_0221171920×2615 840 KB

17

I think I figured it out.

I remembered that both units (cold and hot) are plugged via a smart outlet which can also measure the power consumption. I decided to compare current’s consumption for both units while they idle, in a hope that the hot device will show more mA’s.

So, test conditions: both GX10 devices are headless and don’t have any wires connected except the power cords. Both are wirelessly connected to the same WiFi7 (6GHz) network, no active ssh/vnc sessions, no programs running, no external network traffic. Both now have the same EC and BIOS firmware versions - downgraded to the “cold” unit’s versions.

As it turns out in this configuration both devices consume the same power according to the outlet’s app - approximately 25W. Yet one of them stays cold and another heats up.

At this point I started thinking what common can be in running an app in a VNC session and connecting the monitor+key+mouse to the device. Yep, raising power consumption a bit. So I did more measurements:

  1. VNC session + System Monitor running: the unit consumes +8W, probably mainly due to drawing and continuously sending screen updates via WiFi radio
  2. Connecting a monitor (180Hz QHD) + key + mouse: the unit consumes +13W. This was a surprise to me until I realized that my keyboard has 105 LEDs and also it is connected via a USB hub in a laptop’s cooling pad with huge fans inside, hence enough load

I decided to do one extra test - no monitor, no VNC etc, but just connecting some USB load (5-10W) to the device. I was looking for a HDD in a USB3 enclosure when I realized that the phone I hold in my hands should be the perfect load. So I disabled fast charging and connected it to (already idle-hot) GX10. With the screen off the phone was adding around 9W to the unit’s consumption.

Predictably, the fan started rotating faster. And, the device quickly got to this state while continuning to charge the phone at the same time:

| N/A   38C    P8              2W /  N/A  | Not Supported          |      0%      Default |

mt7925_phy0-pci-90100
Adapter: PCI adapter
temp1:            N/A  

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +40.8°C  
temp2:        +37.8°C  
temp3:        +37.9°C  
temp4:        +38.0°C  
temp5:        +37.9°C  
temp6:        +40.8°C  
temp7:        +38.5°C  

nvme-pci-40100
Adapter: PCI adapter
Composite:    +40.9°C  (low  =  -5.2°C, high = +82.8°C)
                       (crit = +84.8°C)
Sensor 1:     +40.9°C  (low  = -273.1°C, high = +65261.8°C)

\_TZ_.TSOC      40800
\_TZ_.TS0E      37800
\_TZ_.TS0P      37900
\_TZ_.TS1E      38000
\_TZ_.TS1P      37900
\_TZ_.TGPU      40800
\_TZ_.TUNC      38600

All these test results mean that at least in a low-power state DGX Spark has fan control based on unit’s power draw, not temperature readings.

Connecting any kind of load to the unit makes the fan to rotate faster. Similarly, increasing power usage on the device itself (like sending continuous flow of data via WiFi) also works.

This even explains why connecting a CX7 cable also workarounds the problem - CX7 NIC simply increases power consumption.

@dmayer1 Try to reproduce this results - instead of the monitor, try to connect and charge a smartphone via TypeC while the device overheats in idle.

To summarize, all this points to EC controller’s low fan curves being bound to the unit’s power consumption and not to the temperature. And maybe differences in thermal pasting/materials quality might produce variations in fan’s performance in a given RPM range, resulting in the same fan curves being insufficient for some devices.

18

Very interesting … right now I have a monitor plugged in to HDMI and a keyboard dongle into the USB-c port.. I was using bluetooth for the keyboard and mouse but i had a hard time waking the spark up once the screen went black. I will look over this and try something when i get back to the house and report back.. Thank you @x1917x for the suggestion and exploration..

19

Also, as the charging phone consumes less while getting close to 100% charge, I wanted to catch the actual consumption threshold when the fan starts to slow down (and temperature starts to raise again).

Turns out it starts approximately at +4…4.5W, but I don’t think this power outlet has enough accuracy to tell precisely. Should be safe to say that 5V/1A is the minimal load value to get a boost to the fan’s rpm.

Having the phone reached the full charge, the device expectedly started to heat up again - with absolutely zero changes in the setup except the charge current.

20

Hi all — thank you especially @x1917x for the systematic testing in posts 15-19. The power draw correlation you’ve demonstrated — USB load spinning the fans back up, threshold around 4-5W, unit cooling to 38°C — is the clearest signal in this thread and we’re taking it directly to engineering.

One data request while they dig in: @x1917x, what driver version is currently installed on your cold unit? (nvidia-smi will show it.) That would be helpful to confirm.

In the meantime, the most reliable workarounds from what the community has found:

xset -dpms to disable display sleep if you use a monitor
VNC with an active rendering app (idle VNC session is not sufficient)
Any sustained USB load on the device
Do not leave the unit fully idle and headless without one of the above in place
@dmayer1 — your field diagnostic failure is still grounds for RMA regardless of this investigation. Please open a case with NVIDIA support if you haven’t already.

We’ll update here as we have more to share.

~ Neill

21

580.159.03
I actually tried to downgrade the driver version for the hot unit (which has 580.173.02), but turns out it’s not that simple - even after specifying versions for all dependencies, I’ve got an error from dpkg at the end of the installation, something about that it cannot overwrite a binary. It aborts the installation and then I had to do apt --fix-broken installto revert back. Haven’t checked it further, perhaps there is a way to tell dpkg to force-overwrite the conflicting binary file.

This was the command I tried:

sudo apt install \
    libnvidia-gpucomp-580=580.159.03-1ubuntu1 \
    libnvidia-cfg1-580=580.159.03-1ubuntu1 \
    nvidia-persistenced=580.159.03-1ubuntu1 \
    libnvidia-compute-580=580.159.03-1ubuntu1 \
    libnvidia-decode-580=580.159.03-1ubuntu1 \
    libnvidia-encode-580=580.159.03-1ubuntu1 \
    xserver-xorg-video-nvidia-580=580.159.03-1ubuntu1 \
    libnvidia-fbc1-580=580.159.03-1ubuntu1 \
    nvidia-driver-580-open=580.159.03-1ubuntu1 \
    nvidia-firmware-580=580.159.03-1ubuntu1 \
    nvidia-dkms-580-open=580.159.03-1ubuntu1 \
    nvidia-kernel-common-580=580.159.03-1ubuntu1 \
    nvidia-kernel-source-580-open=580.159.03-1ubuntu1 \
    libnvidia-gl-580=580.159.03-1ubuntu1 \
22

I spent a good deal of time on this today and last night. I had claude and astra pointed at it to try and figure it out and they failed. Then claude mentioned that my connectx7 port was not connected on my newest 5th spark I bought this week that had the issue. I had done that on purpose because this was not suppose to join my quad spark mesh, but I realized the connectx cable must cause some type of load on the pc or something and I thought I bet that was the main issue. Luckily I was able to do some validation on kernels and everything against my other 4 sparks to kind of figure this out but once I pointed claude at that and we tried a few things the issue finally was resolved. Below is a summary of how we got it working. Basically, we kill the thing that causes that shut down of that connectx port shortly after boot.

FIX:
Adding a root cause for single-Spark / uncabled units, plus a software-only workaround that survives reboots.

Setup: 5 Sparks. Four are cabled to a MikroTik CRS804 over ConnectX-7 and have never shown this problem. The fifth (bought Sept 2026) runs standalone with nothing in either QSFP port. Only the fifth overheats at idle: fans run at boot, stop within minutes, chassis gets too hot to touch, fans come back for shutdown and when I charge a phone off USB-C.

What the logs show on the uncabled unit: at boot mlx5_core finds the CX7 normally and names the ports. About 16 seconds later:

cx7-pcie-hotplug MTKP0001:00: Cable removal

and the CX7 is torn off the PCIe bus. It disappears from lspci and fwupdmgr get-devices. The cabled units load the same driver (mtk_pcie_hotplug, “CX7 PCIe Hotplug Driver for NVIDIA DGX Systems”) but never fire the removal.

That ties directly to @x1917x’s finding that the EC runs the fans off power draw at idle. With the CX7 powered off, a lone Spark drops below the EC’s idle fan threshold, and the fans stop even while temperature climbs. Cabled units stay above it because the CX7 is powered.

Firmware ruled out: one of my cabled, unaffected units runs identical firmware to the affected one (EC 0x03000508, SoC 0x02009b0b, USB-C PD 0x516). Kernel is also ruled out: the affected unit shows it on both 6.17.0-1014-nvidia and 7.0.0-1019-nvidia.

Workaround: block the hotplug module so the CX7 stays powered with no cable:

printf 'blacklist mtk_pcie_hotplug\ninstall mtk_pcie_hotplug /bin/false\n' | sudo tee /etc/modprobe.d/no-cx7-hotplug.conf
sudo update-initramfs -u -k $(uname -r)
sudo reboot

After reboot: module not loaded, no “Cable removal” event, all four CX7 ports present (DOWN, no cable), and the fans keep running at idle. Trade-off: the CX7 stays powered (~17 W per another thread here), which is exactly why it works.

Undo: sudo rm /etc/modprobe.d/no-cx7-hotplug.conf && sudo update-initramfs -u -k $(uname -r) && sudo reboot

Affected unit: DGX Spark FE, board P4242 A04, BIOS 5.36_0ACUM027 (06/12/2026), DGX OS 7.6.0, driver 580.178.04.

@Neill: this suggests the idle fan logic fails on any Spark without a cable in the CX7, which is every single-unit owner. Happy to share logs.