NVIDIA / NVIDIA/open-gpu-kernel-modules
GPU power draw stuck at a fixed value above the power limit, causing permanent clock throttle on RTX 5090 Laptop GPU
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 17.4k
- Forks
- 1.9k
- PR merge metrics
- No merged PRs in 30d
Description
NVIDIA Open GPU Kernel Modules Version
610.57.04 [from RPMFusion, akmods-nvidia-open]
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 Linux 44 x86_64 (KDE Plasma Desktop Edition)
Kernel Release
Linux fedora 7.1.7-200.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Aug 6 21:13:02 UTC 2026 x86_64 GNU/Linux
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
GPU 0: NVIDIA GeForce RTX 5090 Laptop GPU (UUID: GPU-2d5f3677-1270-2170-24f2-a09694ea480a)
Describe the bug
After moving to the 610.x driver branch, nvidia-smi reports a fixed, implausible power draw value that exceeds the card's own maximum power limit. This keeps the SW Power Cap clock throttle permanently active, so the GPU core and SM clocks stay near idle even at 100 percent utilization. This makes the GPU unusable for any real workload. Reproduces from a clean boot before any application touches the GPU, and is independent of display configuration (internal panel only, or with external displays attached).
Environment
- GPU: NVIDIA GeForce RTX 5090 Laptop GPU (GB203M), PCI ID 10de:2c18
- Driver: 610.57.04, open kernel module (also reproduces on 610.43.03)
- Kernel: 7.1.7-200.fc44.x86_64
- Distro: Fedora 44, open driver packages from RPM Fusion
- Laptop: ASUS ProArt P16 (H7606WX), BIOS H7606WX.304
- Graphics setup: hybrid, AMD Radeon 880M/890M (iGPU) drives all display outputs including the internal panel, NVIDIA GPU used through PRIME render offload only, no direct display connection. supergfxctl mode: Hybrid.
- Sleep mode: s2idle is the only option exposed under /sys/power/mem_sleep
What has been ruled out
nvidia-smi -lgc <min>,<max>to force a clock floor: the command reports success but has no effect, clocks stay pinned and SW Power Cap keeps overriding it.nvidia-smi -pm 1, persistence mode: no change, tested both enabled and disabled.- Full reboot: the same fixed power draw value and throttle reappear immediately after boot, before launching anything, so this is not a one-off stuck register from a suspend cycle.
- nvidia-powerd: running, connects over DBus with no errors in its logs.
- Display configuration: reproduces with internal display only and with external displays attached, so this is not related to reverse PRIME or multi-monitor output.
To Reproduce
- Boot the system, do not run anything that touches the GPU yet.
- Run
nvidia-smi -q -d POWER,PERFORMANCE,CLOCK. - Power draw (both average and instantaneous) is reported as a fixed value, 432.99 W on this system, well above the 130 W max power limit reported for the same GPU.
- Under Clocks Event Reasons, SW Power Cap shows Active, and the counter for it increases continuously across the whole session.
- Launch a GPU-bound application through PRIME render offload (
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia). - GPU utilization reaches 100 percent, but Graphics/SM clocks stay in the 172 to 225 MHz range. Max clocks reported by the driver for this GPU are 3090 MHz.
Bug Incidence
Always
nvidia-bug-report.log.gz
More Info
This is related to https://github.com/NVIDIA/open-gpu-kernel-modules/issues/1237 - I am not sure if this constitutes a duplicate given our hardware configuration is quite different. I have decided to file anyway in the hopes that the information is useful, and leave it to you as to whether this is a true duplicate or merely a related issue.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by running nvidia-smi -q -d POWER,PERFORMANCE,CLOCK after a clean boot and review the linked nvidia-bug-report.log.gz. Compare the behavior with related issue #1237 and trace the open GPU kernel module power and clock reporting paths. Done means the reported draw is within the 130 W limit and GPU-bound workloads no longer remain under SW Power Cap at idle clocks.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, linux
- Domain
- operating-systems, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100