RE: [drm/amd #3549] Navi 33 idle sclk latch: repro, analysis, userspace workaround

AMD General

What’s the GPU utilization(observed by sudo cat /sys/kernel/debug/dri/x/amdgpu_pm_info) when the sclk is highest?
The policy is that if the utilization is 100%, the clock has to stay highest.
Could you please elaborate what ‘a tiny job’ is to trigger the issue?
Thanks.


From: amd-gfx <[email protected]> On Behalf Of Kevin Hake
Sent: Sunday, August 23, 2026 11:05 PM
To: [email protected]
Cc: Deucher, Alexander <[email protected]>
Subject: [drm/amd #3549] Navi 33 idle sclk latch: repro, analysis, userspace workaround

Some people who received this message don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

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