NVIDIA Open GPU Kernel Modules Version
610.43.02
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.
Haven't yet tested against the proprietary driver - Blackwell laptop GPUs
(including this one) ship with the open kernel modules only as far as I'm
aware, so I'm not sure a proprietary-driver comparison is even possible
here. If it is possible, happy to test.
Operating System and Version
Ubuntu 26.04 LTS
Kernel Release
Linux ThinkPad-P14s-Gen-6 7.0.0-30-generic #30-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 31 18:22:54 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.
Hardware: GPU
GPU 0: NVIDIA RTX PRO 1000 Blackwell Generation Laptop GPU (UUID: GPU-85870bda-2813-18ad-bfa8-ae4ed9007837)
Describe the bug
GPU power draw is hard-capped at ~24-25W under Linux regardless of driver-reported
limits (default 35W, max 50W per nvidia-smi -q -d POWER), nvidia-smi -pl,
power-profiles-daemon mode, or ACPI platform_profile. nvidia-powerd runs
cleanly with no errors (v2.0, DBus connected), but a kernel-level NVRM assertion
at boot shows PlatformRequestHandler failing to query the platform power mode
from SBIOS:
NVRM: GPU0 nvAssertOkFailedNoLog: Assertion failed: Invalid data passed
[NV_ERR_INVALID_DATA] (0x00000025) returned from PlatformRequestHandler
failed to get platform power mode from SBIOS @ platform_request_handler_ctrl.c:2117
This fires at driver init, before nvidia-powerd negotiates anything - so the
daemon is running against an already-broken foundation. Under identical
benchmark settings, Windows 11 on the same hardware reaches at least 38.9W GPU
power draw and delivers ~47% higher FPS (57.4 vs 39.x FPS in Total War:
Warhammer III, 2560x1600, High, 66% resolution scale). Thermal headroom is not
the limiting factor - GPU temp was 63C against an 87C thermal limit ceiling
(per Windows telemetry) during the capped Linux run.
This matches a pattern reported across multiple laptop vendors on this and
adjacent GPUs, where NVIDIA's Dynamic Boost/PlatformRequestHandler mechanism
depends on a vendor-specific ACPI/WMI method that Windows OEM tooling (Lenovo Commercial
Vantage in this case) calls correctly, but which fails or is unavailable via
the generic Linux ACPI/WMI path:
Note: on driver 595.x, nvidia-powerd crashed on nearly every boot on this
system, consistent with the Dell Pro Max GC6/GSP-heartbeat bug above (same
GPU). Switching to 610.43.02 resolved the crash, but the underlying power
negotiation now fails differently (SBIOS query error above) rather than being
fixed.
Checked the full Lenovo BIOS changelog history for this platform (UEFI 1.03
through the latest 1.26, Apr 2025-Aug 2026) - no release mentions GPU power
delivery, Dynamic Boost, NvPCF, or ACPI/WMI power-mode fixes, so a BIOS update
is not expected to resolve this.
To Reproduce
- System: Lenovo ThinkPad P14s Gen 6, Core Ultra 7 265H, NVIDIA RTX PRO 1000
Blackwell Laptop GPU (GB207GLM), hybrid graphics (PRIME on-demand)
- Driver: 610.43.02 (open kernel modules), installed via Canonical's
precompiled path
- BIOS: R2WET43W (UEFI 1.25 / EC 1.15)
- Boot the system normally on AC power
- Check
dmesg -T | grep -iE 'thermal|throttl|power' -> observe the
PlatformRequestHandler/SBIOS assertion above at boot
- Run
nvidia-smi -q -d POWER -> Current/Default Power Limit reports 35W,
Max Power Limit reports 50W
- Run any sustained 100% GPU load (used: Total War: Warhammer III benchmark,
2560x1600, High settings, 66% resolution scale) and monitor nvidia-smi
during the run
- Observe: GPU stays pinned at P4 performance state, ~24-25W power draw,
100% utilization, well below both the reported 35W default and 50W max
- Attempt
sudo nvidia-smi -pl 50 -> fails with "Changing power management
limit is not supported in current scope for GPU"
- Attempt switching power-profiles-daemon to performance mode -> no change
in GPU power draw
- Attempt setting ACPI platform_profile to performance (already at max of
low-power/balanced/performance) -> no change
- Confirm nvidia-powerd is running without errors
(systemctl status nvidia-powerd) -> daemon is healthy, no crash
- Reboot into Windows 11 on the same hardware, same AC power, same benchmark
settings -> GPU power draw reaches at least 38.9W, benchmark averages
57.4 FPS vs 39.x FPS on Linux
Bug Incidence
Always
nvidia-bug-report.log.gz
nvidia-bug-report.log.gz.txt
More Info
Attached log is named nvidia-bug-report.log.gz.txt because I couldn't upload
a .gz file - it's the unmodified output of
sudo nvidia-bug-report.sh, just rename back to .gz before decompressing.
Additional context:
- Secure Boot: enabled
- prime-select: on-demand (hybrid graphics)
- Currently installed BIOS (R2WET43W / UEFI 1.25) is one release behind the
latest available (UEFI 1.26, released 2026-08-11), but that release's
changelog contains no power-management-related fixes, so I don't expect
it to change this behavior. Happy to update and re-test if a maintainer
thinks it's worth ruling out anyway.
- Haven't yet tested against the proprietary driver - Blackwell laptop GPUs
(including this one) ship with the open kernel modules only as far as I'm
aware, so I'm not sure a proprietary-driver comparison is even possible
here. If it is possible, happy to test.
- What I expected: GPU power draw to scale up toward the driver-reported
35W default (and ideally the 50W max) under sustained full load, matching
what's observed on Windows on the same hardware. What actually happens:
power draw stays pinned at ~24-25W regardless of load, with the SBIOS
query failure in dmesg as the likely root cause.
NVIDIA Open GPU Kernel Modules Version
610.43.02
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.
Haven't yet tested against the proprietary driver - Blackwell laptop GPUs
(including this one) ship with the open kernel modules only as far as I'm
aware, so I'm not sure a proprietary-driver comparison is even possible
here. If it is possible, happy to test.
Operating System and Version
Ubuntu 26.04 LTS
Kernel Release
Linux ThinkPad-P14s-Gen-6 7.0.0-30-generic #30-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 31 18:22:54 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.
Hardware: GPU
GPU 0: NVIDIA RTX PRO 1000 Blackwell Generation Laptop GPU (UUID: GPU-85870bda-2813-18ad-bfa8-ae4ed9007837)
Describe the bug
GPU power draw is hard-capped at ~24-25W under Linux regardless of driver-reported
limits (default 35W, max 50W per
nvidia-smi -q -d POWER),nvidia-smi -pl,power-profiles-daemonmode, or ACPIplatform_profile.nvidia-powerdrunscleanly with no errors (v2.0, DBus connected), but a kernel-level NVRM assertion
at boot shows
PlatformRequestHandlerfailing to query the platform power modefrom SBIOS:
This fires at driver init, before
nvidia-powerdnegotiates anything - so thedaemon is running against an already-broken foundation. Under identical
benchmark settings, Windows 11 on the same hardware reaches at least 38.9W GPU
power draw and delivers ~47% higher FPS (57.4 vs 39.x FPS in Total War:
Warhammer III, 2560x1600, High, 66% resolution scale). Thermal headroom is not
the limiting factor - GPU temp was 63C against an 87C thermal limit ceiling
(per Windows telemetry) during the capped Linux run.
This matches a pattern reported across multiple laptop vendors on this and
adjacent GPUs, where NVIDIA's Dynamic Boost/PlatformRequestHandler mechanism
depends on a vendor-specific ACPI/WMI method that Windows OEM tooling (Lenovo Commercial
Vantage in this case) calls correctly, but which fails or is unavailable via
the generic Linux ACPI/WMI path:
assertion. https://forums.developer.nvidia.com/t/nvrm-failed-to-get-target-temp-from-sbios-failed-to-get-platform-power-mode-from-sbios-on-rtx-4050-laptop-gpu/375988
root-caused to the Linux hp-wmi driver skipping a required WMI unlock call.
https://forums.developer.nvidia.com/t/hp-omen-max-16-rtx-5080-laptop-gpu-tgp-locked-at-80w-on-linux-nvidia-powerd-receives-sbios-disable-signal-board-8d41/369242
a related GSP-RM heartbeat/GC6 bug on driver 595.x affecting the same power
management subsystem. https://forums.developer.nvidia.com/t/gsp-rm-firmware-bug-heartbeat-stops-after-gc6-exit-leads-to-fatal-gpu-loss-xid-79-and-broken-display-recovery/366591
Note: on driver 595.x, nvidia-powerd crashed on nearly every boot on this
system, consistent with the Dell Pro Max GC6/GSP-heartbeat bug above (same
GPU). Switching to 610.43.02 resolved the crash, but the underlying power
negotiation now fails differently (SBIOS query error above) rather than being
fixed.
Checked the full Lenovo BIOS changelog history for this platform (UEFI 1.03
through the latest 1.26, Apr 2025-Aug 2026) - no release mentions GPU power
delivery, Dynamic Boost, NvPCF, or ACPI/WMI power-mode fixes, so a BIOS update
is not expected to resolve this.
To Reproduce
Blackwell Laptop GPU (GB207GLM), hybrid graphics (PRIME on-demand)
precompiled path
dmesg -T | grep -iE 'thermal|throttl|power'-> observe thePlatformRequestHandler/SBIOS assertion above at boot
nvidia-smi -q -d POWER-> Current/Default Power Limit reports 35W,Max Power Limit reports 50W
2560x1600, High settings, 66% resolution scale) and monitor
nvidia-smiduring the run
100% utilization, well below both the reported 35W default and 50W max
sudo nvidia-smi -pl 50-> fails with "Changing power managementlimit is not supported in current scope for GPU"
in GPU power draw
low-power/balanced/performance) -> no change
(
systemctl status nvidia-powerd) -> daemon is healthy, no crashsettings -> GPU power draw reaches at least 38.9W, benchmark averages
57.4 FPS vs 39.x FPS on Linux
Bug Incidence
Always
nvidia-bug-report.log.gz
nvidia-bug-report.log.gz.txt
More Info
Attached log is named nvidia-bug-report.log.gz.txt because I couldn't upload
a .gz file - it's the unmodified output of
sudo nvidia-bug-report.sh, just rename back to .gz before decompressing.Additional context:
latest available (UEFI 1.26, released 2026-08-11), but that release's
changelog contains no power-management-related fixes, so I don't expect
it to change this behavior. Happy to update and re-test if a maintainer
thinks it's worth ruling out anyway.
(including this one) ship with the open kernel modules only as far as I'm
aware, so I'm not sure a proprietary-driver comparison is even possible
here. If it is possible, happy to test.
35W default (and ideally the 50W max) under sustained full load, matching
what's observed on Windows on the same hardware. What actually happens:
power draw stays pinned at ~24-25W regardless of load, with the SBIOS
query failure in dmesg as the likely root cause.