RTX 2000 Ada Laptop (AD107GLM): frozen bogus power telemetry (~588 W reading on 35 W part) causes permanent SW Power Cap — clocks pinned at 210 MHz (610.43.02/610.43.03, GSP)

NVIDIA Open GPU Kernel Modules Version

610.43.03 (also reproduces on 610.43.02 — see regression window in More Info)

Please confirm this issue does not happen with the proprietary driver (of the same version). This issue tracker is only for bugs specific to the open kernel driver.

• I confirm that this does not happen with the proprietary driver package.

Operating System and Version

Fedora 44 Silverblue-based (secureblue silverblue-nvidia-open-hardened, image 44.20260710.0)

Kernel Release

7.1.3-200.fc44.x86_64

Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.

• I am running on a stable kernel release.

Hardware: GPU

NVIDIA RTX 2000 Ada Generation Laptop GPU (AD107GLM, 8 GB) — hybrid graphics with Intel UHD iGPU (i9-14900HX), HP ZBook Fury 16 G11

Describe the bug

GPU power telemetry returns a frozen, physically impossible reading of ~588–590 W (the part has a 35 W current / 45 W default power limit). As a result, "SW Power Cap" is permanently active from GPU initialization onward — the cap counter tracks wallclock ~1:1 (measured +91.97 s of cap time over a 92.6 s window, fully idle) — and SM/graphics clocks never leave 210 MHz (max: 3105 MHz), regardless of load. Every GPU workload (Vulkan via PRIME offload and native CUDA) runs at roughly 7% of normal performance. Under load, "SW Thermal Slowdown" also flags Active at 48–50 °C, which looks like the same broken telemetry.

Idle:

$ nvidia-smi --query-gpu=pstate,utilization.gpu,clocks.sm,power.draw,temperature.gpu --format=csv,noheader
P8, 0 %, 210 MHz, 588.21 W, 44

Clocks Event Reasons: SW Power Cap : Active
GPU Power Readings:   Average Power Draw:       588.21 W
                      Instantaneous Power Draw: 588.21 W   (frozen; moves only 588.21 -> 590.01 across hours)
                      Current Power Limit:      35.00 W  (Requested/Default: 45.00 W)
Clocks:               SM 210 MHz  (Max: SM 3105 MHz)

Under sustained CUDA load (LLM inference, 7 GB VRAM in use):

P3, 100 %, 210 MHz, 590.01 W, 50
P3, 100 %, 210 MHz, 590.01 W, 49    (15 samples: clock never leaves 210 MHz)
SW Thermal Slowdown : Active        (at 48-50 °C, i.e. bogus)

Ruled out:

• Thermals: 44–50 °C throughout.
• Runtime PM: device in D0, runtime_status=active, nvidia-smi responds instantly; Runtime D3: Enabled (fine-grained).
• Zero Xid/NVRM errors in the kernel log for the entire boot.
• nvidia-powerd (Notebook Dynamic Boost: Supported): started, and also restarted while the GPU was under 100% load — no effect. (Side note: nvidia-powerd never autostarts here because ConditionPathExistsGlob=/dev/nvidia* is evaluated before the device nodes exist at boot; starting it manually does not change the capping, so it is not the cause.)
• Userspace mismatch: reproduces identically in native CUDA (ollama) and Vulkan (flatpak with exactly matching GL extension).

To Reproduce

1. Boot this laptop (hybrid graphics, RTX 2000 Ada as PRIME offload device) on kernel 7.0.14+ with open kernel modules 610.43.02 or 610.43.03 and linux-firmware 20260622 or newer.
2. Run any workload on the NVIDIA GPU (Vulkan game via PRIME offload, or CUDA inference).
3. Observe nvidia-smi --query-gpu=pstate,utilization.gpu,clocks.sm,power.draw,temperature.gpu --format=csv,noheader -l 1 and nvidia-smi -q -d PERFORMANCE,POWER,CLOCK: utilization reaches 100%, pstate rises to P3, but SM clock stays at 210 MHz, power draw reads a frozen ~588–590 W, and SW Power Cap remains Active (also at idle).

Bug Incidence

Always

nvidia-bug-report.log.gz

nvidia-bug-report.log.gz

More Info

Regression window — the same driver version (610.43.02) is good on kernel 7.0.12 + linux-firmware 20260519 and broken from kernel 7.0.14 + linux-firmware 20260622 onward, which suggests a kernel/firmware interaction with GSP power telemetry rather than the driver userspace:

Image build   Kernel   linux-firmware  Driver     Result
2026-06-26    7.0.12   20260519        610.43.02  OK (normal clocks)
2026-07-05    7.0.14   20260622        610.43.02  BROKEN (from first session)
2026-07-08    7.1.3    (newer)         610.43.02  BROKEN
2026-07-10    7.1.3    (newer)         610.43.03  BROKEN (measurements above)

Note on the proprietary-driver confirmation: I cannot test the proprietary kernel module package on this system (immutable Fedora Silverblue-based image that ships the open modules only). Given the telemetry originates in GSP, the issue may or may not be specific to the open modules — please redirect me if this belongs on the forums.

Possibly related: https://forums.developer.nvidia.com/t/rtx-4050-laptop-stuck-in-p3-low-power-cap-when-ac-is-plugged-in-during-gpu-load-restarting-nvidia-powerd-fixes-it/375678 — similar permanent SW Power Cap on 610.43.02, but there an nvidia-powerd restart clears it; on my machine it does not, and that report does not show the frozen 588 W reading.

Start by comparing the nvidia-smi POWER and PERFORMANCE queries, kernel logs, and nvidia-bug-report.log.gz across the working 7.0.12/20260519 and failing kernel/firmware combinations. Trace the GSP power-telemetry path and verify that the fix reports plausible power and thermal values, clears the SW Power Cap, and allows clocks to rise under CUDA or Vulkan load.