Hi all,
Follow-up to drm/amd issue #3549 ("AMD GPU usage peaks with system in idle —
Radeon RX 7600 XT"), where I posted a root-cause analysis and reproducer
a few weeks ago (note 3586398). The thread's been quiet, so I'm summarizing
here in case it's useful to whoever owns PMFW/swsmu for SMU 13.0.7.
Behavior (RX 7600 XT / Navi 33, kernels 6.x–7.1, likely any DE (tho I'm on
Plasma w/Wayland) or bare TTY):
- With the gfx job stream verifiably empty, a single tiny job submitted
while sclk is at 0 (deep sleep) latches sclk at max (~2990 MHz, ~115 W)
indefinitely. A second completed gfx job clears it. So at true idle the
card toggles between 0 and max on every stray job, and can sit at max
for an hour with the screen off.
- Light sustained load (video, a compositor, radeontop) masks it, which
is why the earlier "monitoring tools toggle gfxoff" hypothesis looked
plausible. It reproduces on demand from a TTY with nothing polling.
- Umio's finding that disabling GFXOFF via ppfeaturemask stops the spikes
is consistent with this model: without GFXOFF there is no "single job
from deep sleep" transition to mis-handle.
How I measured:
- Job stream: a private ftrace instance on amdgpu_cs_ioctl /
amdgpu_sched_run_job / drm_sched_job_done, cross-checked against fdinfo
drm-engine counters and debugfs amdgpu_fence_info, so I could prove the
kernel submitted nothing while clocks moved.
- Clock: sampling the firmware's gpu_metrics (v1.3) at 1 kHz, matched to
the driver's 1 ms refresh of that table, to catch the ramp edges.
- Stimulus: a minimal compute dispatch with a held context (no setup/
teardown jobs), and later a one-packet PM4 NOP via libdrm — either one
toggles the latch.
Everything points at the firmware's clock selection rather than the driver.
Since PMFW can't be patched from outside, I published a small userspace
workaround: a C daemon over libdrm/render node that submits one PM4 NOP
when it sees sclk latched (same binary is the manual reproducer):
https://github.com/KevinHake/amdgpu-unstick
Scripts, logs, and an asciinema demo are attached to the issue. If a
narrower repro would help (specific firmware versions, mesa-free path,
other kernels), tell me what you need and I'll run it.
Thanks,
Kevin Hake
