When Doing More Made My AI Workstation Cooler
An ASUS Ascent GX10 cooling mystery—and what a failed firmware probe might have taught us.
Two machines, two different idle temperatures
I recently investigated an unusual cooling problem with one of my ASUS Ascent GX10 AI workstations. Two machines were sitting side by side, with similar positioning and ventilation. One stayed around the mid-30s Celsius at idle. The other regularly reached 55–57°C, despite reporting 0% GPU utilization and roughly 4 W of GPU power.
The warmer machine also seemed to move less air. Neither NVIDIA’s monitoring tools nor the available Linux hardware-monitoring interfaces exposed fan RPM, so that remained a physical observation rather than a measurement.
What followed, working with an AI coding assistant, became an investigation into the difference between workload, power state, and cooling behavior.
More activity, lower temperature
The first useful clue came from an earlier observation: the warmer machine seemed to cool down when an Ollama model was loaded, even after generation had finished.
We tested that deliberately. We sent a short request to a 27-billion-parameter model and kept it resident for 20 minutes. The response finished; the model then remained in GPU-accessible memory without generating.
| Condition | Temperature | GPU power |
|---|---|---|
| Idle, no model loaded | 57°C | 4.09 W |
| Model resident, no generation | 47°C | 10.63 W |
| Several minutes later | 41°C | 9.78 W |
Eventually, the temperature reached approximately 39°C, matching the other workstation. The machine was cooler while reporting more GPU power consumption.
After the model unloaded, the GPU returned to its low-power P8 state. Its temperature gradually rose again. This suggested that cooling behavior depended on something beyond GPU temperature alone. It did not yet tell us whether the cause was a driver, firmware policy, controller state, or physical cooling difference.
A phone became a diagnostic tool
We then tried charging a phone from one of the workstation’s USB ports. With no model loaded, the GPU remained in P8 at 0% utilization, yet its temperature fell from 49°C to 44°C in about 90 seconds, and later reached around 40°C.
There was a complication: I had also switched the KVM shortly before connecting the phone. We therefore could not attribute that initial drop solely to charging.
We unplugged only the phone, leaving the KVM connected. The temperature initially stayed low, then began rising again. That strengthened the possibility of a cooling response associated with USB activity or overall system power. However, we had no wall-power meter or fan tachometer. The power figures above were GPU readings, not total system consumption.
Firmware updates were not the immediate answer
We updated the BIOS and SoC firmware, then separately updated the embedded controller:
- BIOS: 0105 → 0106
- SoC: 3.0.7 → 3.0.8
- EC: 3.3.2.4 → 3.5.11.4
The updates completed successfully, but the workstation still reached 50–52°C at idle afterward.
Another useful finding: Linux had reported an apparently outdated USB-C PD firmware version. The BIOS screen showed that PD 5.22 was already installed in both banks of both PD controllers. The later BIOS update corrected Linux’s reporting. An update-history error had looked like an installation failure, but it was not reliable evidence that the controller was still running old firmware.
The failed probe—and the unexpected recovery
To investigate fan speed, we examined an experimental open-source DGX Spark fan-control project by Christopher Owen. Its ASUS compatibility was unverified, but our machine exposed the same firmware-service identifier.
We built a much smaller diagnostic module that requested only capabilities and, if those matched, telemetry. It contained no fan-speed setting commands. We signed it, enrolled its certificate, and kept Secure Boot enabled.
The probe failed. The firmware returned status 0x05 during the capability request. No RPM telemetry was retrieved. The module unloaded after each attempt. The upstream code names that status an eSPI read failure; its exact meaning on ASUS was not independently verified.
Then we noticed something unexpected: the workstation was cool again—approximately 39°C, with no model loaded, no phone connected, and the GPU in P8 at around 3 W. It remained cool during subsequent observation.
Did the request wake a stuck controller?
That is my working hypothesis, not a demonstrated explanation. Perhaps communication with the firmware caused a controller task, mailbox, or cooling-policy state to be reevaluated. A request can have internal side effects even when it contains no command to change fan speed.
But there are important limits: we had rebooted for certificate enrollment, lacked an immediate pre-probe temperature measurement, and had not isolated every display-related variable. We did not observe an interrupt or measure a fan-speed change. The two machines also differed in kernel and driver versions, and later in firmware versions.
We observed a recovery. We did not prove its mechanism or establish a permanent fix.
The next meaningful test would be to reproduce the warm condition and repeat one identical probe without changing anything else.
For me, the lesson is that “idle” is not one simple hardware state—and a failed diagnostic request can still be followed by an important observation. The challenge is to document that observation without prematurely turning it into a causal explanation.
If you work on embedded-controller firmware or GB10 platforms, I would be interested in how you would distinguish an activity-dependent fan policy from a stalled controller or communication state.
How to investigate a similar cooling issue
These steps describe our investigation on an ASUS Ascent GX10. They are a diagnostic procedure, not a confirmed repair. Firmware packages and controller interfaces can differ between GB10 products.
1. Record the idle baseline
Before making changes, record temperature, GPU activity, power state, driver version, and uptime. Run these commands in a terminal on the workstation you are testing:
nvidia-smi --query-gpu=name,driver_version,temperature.gpu,utilization.gpu,power.draw,pstate,clocks.gr --format=csv
uname -r
uptime
ollama psAllow the machine time to settle after boot. Keep room conditions, connected devices, display/KVM selection, and workloads unchanged. Zero GPU utilization does not mean the entire machine is inactive.
2. Inspect firmware versions before updating
Collect the operating system’s view:
fwupdmgr get-devices
fwupdmgr get-history
fwupdmgr get-updatesOn our GX10, we also checked BIOS → Advanced → Firmware Version Information. This mattered: Linux initially reported an incorrect PD version while BIOS showed 5.22 installed. Do not assume an old failure in update history describes the currently installed firmware.
3. Test model residency without sustained generation
If Ollama is installed, choose an existing model using ollama list. Replace YOUR_INSTALLED_MODEL below with its exact name. Run this command on the machine running Ollama; the loopback address refers to that machine.
curl http://127.0.0.1:11434/api/generate \
-H 'Content-Type: application/json' \
-d '{
"model": "YOUR_INSTALLED_MODEL",
"prompt": "Reply with only the word OK.",
"stream": false,
"keep_alive": "20m",
"options": {
"num_predict": 16,
"num_ctx": 4096
}
}' Wait for generation to finish. Confirm residency with ollama ps, then record GPU readings every minute. In our test, temperature fell while the model remained loaded without generating. Model behavior and resource use will vary.
4. Observe what happens after unloading
Let the keep-alive expire naturally. Alternatively, only if nobody else is using that model, unload it:
ollama stop YOUR_INSTALLED_MODELConfirm it is no longer resident. Continue recording temperatures for 10–15 minutes. Look for a repeatable trend rather than a single reading.
5. Test USB charging separately
- With the model unloaded, keep the display, KVM, keyboard, and mouse unchanged.
- Connect a partly discharged phone and confirm it is charging.
- Record temperature, GPU power state, and utilization.
- Unplug only the phone.
- Continue recording.
Our first phone test coincided with a KVM switch, which complicated interpretation. Avoid that mistake: change one condition at a time. Without a USB or wall-power meter, this tests the effect of connecting a charging device—not a precisely measured power increase.
6. Apply supported firmware updates, then repeat the baseline
Use firmware offered for the exact machine model through its supported updater. Save the current inventory, stop active jobs, maintain uninterrupted power, and have local access available during reboot. Verify installed versions afterward.
On our machine, BIOS/SoC and EC updates succeeded, but elevated idle temperatures persisted immediately afterward. Updating alone did not demonstrate a fix. Consult ASUS’s update and BIOS verification instructions for the supported procedure; package names in older examples may differ from current releases.
7. Treat controller probing as experimental development
We went beyond normal diagnostics by building a one-shot, signed kernel module based on an experimental GB10 firmware protocol. It requested capabilities before telemetry, contained no fan-setting commands, stopped on unexpected responses, and unloaded after each attempt.
The capability request failed with firmware status 0x05; we never obtained fan RPM. Lower idle temperatures were subsequently observed, but the probe’s causal role remains unproven.
8. Document the outcome accurately
Record hardware, kernel, driver, and firmware versions; timestamped temperatures and workload states; connected USB/display devices; every change and reboot; and whether the behavior returns after unloading, disconnecting, or rebooting.
A useful result can be either a reproducible fix or a reproducible failure. In our case, the accurate conclusion was:
Lower idle temperatures persisted after the diagnostic attempt, but the mechanism and durability of the recovery were not yet established.
Remove serial numbers, credentials, private addresses, and unrelated logs before publishing or sharing a support package.
Technical references
- Christopher Owen: DGX Spark Fan Control — independent experimental project; OEM compatibility is not established.
- Firmware-interface research — reverse-engineered transport and telemetry contract.
- Ubuntu: UEFI Secure Boot — module signing and certificate enrollment.
- Related GX10 owner report — similar cross-unit idle-temperature observations.
- NVIDIA forum discussion of power-draw correlation — related evidence, not proof for our unit.