Blackwell laptop: NPCF (NVDA0820) at \_SB.NPCF not bound — Dynamic Boost / NVPCF inactive on HP OMEN Slim 16t-an000 (board 8D40)
Summary
On an HP OMEN Slim 16t-an000 (DMI board 8D40, RTX 5060 Laptop, BIOS F.13), the NVIDIA Open kernel module 595.71.05 (Blackwell-capable) does not bind the platform-side NVPCF device (Device(NPCF), _HID="NVDA0820") that lives at \_SB.NPCF rather than as a PCIe child of the GPU. Result:
nvidia-smi -q reports Power Management Object: N/A
nvidia-powerd connects D-Bus and then sits silent (no NVPCF negotiation)
power.max_limit is 90 W, enforced.power.limit is 80 W — the firmware-default static cap
- In Windows + OMEN Gaming Hub, this same GPU reaches ~110 W via Dynamic Boost / NVPCF
- The proprietary driver cannot be used as a fallback: it hard-rejects Blackwell with
requires use of the NVIDIA open kernel modules (RmInitAdapter failed! (0x22:0x56:1017))
The firmware is correct. The HP hp-wmi driver writes HPCM (EC offset 0x95) into the firmware allowlist on platform_profile=performance. The chain breaks inside the Open module: it never builds the PMO for an NPCF device that is not a PCIe child of the GPU.
System
|
|
| Model |
HP OMEN Slim 16t-an000 |
| DMI board |
8D40 |
| BIOS |
F.13 (2026-01-21) |
| GPU |
NVIDIA GeForce RTX 5060 Laptop (PCI 10de:2d19) |
| VBIOS |
98.06.2A.80.76 |
| CPU |
Intel Core Ultra 9 285H |
| OS |
CachyOS, kernel 7.0.9-1-cachyos (LTO Clang) |
| Driver |
linux-cachyos-nvidia-open 595.71.05 (GSP firmware: gsp_ga10x.bin, gsp_tu10x.bin + embedded Blackwell) |
nvidia-utils-beta |
595.71.05-1 |
Firmware evidence (ACPI)
Device(NPCF) is defined in SSDT23 at \_SB.NPCF (not as a child of \_SB.PC00.RP12.PXSX). Extract from decompiled SSDT23.dsl:
Device (NPCF)
{
Name (ATPP, 0xF0) // base TPP
Name (DATP, 0x0168) // dynamic adjusted TPP
Method (_HID, 0, NotSerialized)
{
Return ("NVDA0820")
}
Method (_DSM, 4, Serialized)
{
If ((Arg0 == ToUUID ("36b49710-2483-11e7-9598-0800200c9a66")))
{
// ... sub-functions 0/1/2 implemented
ATPP = 0xF0
If ((\_SB.PC00.LPCB.EC0.HPCM == 0x31)) { ... } // performance
ElseIf ((\_SB.PC00.LPCB.EC0.HPCM == 0x21)) { ... }
ElseIf ((\_SB.PC00.LPCB.EC0.HPCM == 0x11)) { ... }
ElseIf ((\_SB.PC00.LPCB.EC0.HPCM == 0x04)) { ... }
ElseIf ((\_SB.PC00.LPCB.EC0.HPCM == 0x14)) { ... }
ElseIf ((\_SB.PC00.LPCB.EC0.HPCM == 0x24)) { ... }
ElseIf ((\_SB.PC00.LPCB.EC0.HPCM == 0x34)) { ... }
}
}
}
DSDT external references confirm NPCF fields are used by AML elsewhere (ATPP, DATP, CTGP, DBAC, DBDC, DTGP, ACBT, AMAT, AMIT, PABS).
ACPI device shows up in sysfs:
/sys/bus/acpi/devices/NVDA0820:00
status: 15 (Enabled + Present + Functional + Show in UI)
path: \_SB_.NPCF
HPCM is updated by the in-tree hp-wmi driver via GM1A (HP WMI cmd 0x1A). Empirical mapping on this board after applying the 8D40 patch (CachyOS issue #157):
platform_profile |
HPCM value |
In firmware allowlist? |
low-power |
0x30 |
no |
balanced |
0x30 |
no |
performance |
0x31 |
yes |
So in performance the AML allowlist check (HPCM ∈ {0x04, 0x11, 0x14, 0x21, 0x24, 0x31, 0x34}) is satisfied and _DSM sub-func 2 of NPCF returns ATPP=DATP.
Userspace evidence
nvidia-smi snapshot, idle (clean boot, no workload):
name : NVIDIA GeForce RTX 5060 Laptop GPU
driver_version : 595.71.05
vbios_version : 98.06.2A.80.76
power.draw : 18.20 W
power.default_limit : 50.00 W
power.min_limit : 5.00 W
power.max_limit : 90.00 W
enforced.power.limit : 80.00 W
clocks_event_reasons.sw_power_cap : Not Active
clocks_event_reasons.sw_thermal_slowdown : Not Active
clocks_event_reasons.hw_thermal_slowdown : Not Active
clocks_event_reasons.hw_power_brake_slowdown : Not Active
Power Management Object: N/A — the PMO is not built.
nvidia-smi -pl 90 (or any value) rejects:
Changing power management limit is not supported in current scope
…because in the NVPCF model the cap is owned by the platform.
nvidia-powerd journal across a full session (fresh boot, with __RM_ENABLE_VERBOSE_OUTPUT=1 exported via a systemd drop-in):
nvidia-powerd version:2.0 (build 1)
DBus Connection is established
Nothing else. No NVPCF init, no error, no fallback warning. The daemon does not emit the strings present in its binary (SBIOS support not found for NVPCF GET_SUPPORTED function, Intel NVPCF failed, Power monitor not supported on this platform. Using fallback configuration., Error in getting the NvPCF static configuration) — it appears to never reach the code paths that would produce them. (__RM_ENABLE_VERBOSE_OUTPUT=1 is confirmed set in /proc/$(pgrep nvidia-powerd)/environ but produces no additional output in 595.71.05.)
Stress evidence: the cap is software, not thermal
To rule out that the 80 W ceiling is thermal, we ran gpu-burn 90 (CUDA cublasGemmEx saturation) and sampled nvidia-smi and hp-wmi hwmon every 2 s. Stable-state results:
| Metric |
Value during 90 s saturation |
power.draw |
79.5 – 80.0 W (flat on enforced.power.limit=80W) |
clocks_event_reasons.sw_power_cap |
Active (entire run) |
clocks_event_reasons.sw_thermal_slowdown |
Not Active |
clocks_event_reasons.hw_thermal_slowdown |
Not Active |
clocks_event_reasons.hw_power_brake_slowdown |
Not Active |
utilization.gpu |
100 % |
clocks.current.graphics |
2160 – 2250 MHz |
temperature.gpu |
56 °C → 70 °C peak (TJmax ≈ 95 °C, ~25 °C headroom) |
Fans (hp-wmi fan1/fan2) |
2600/2200 → 2800/2600 RPM, pwm1 120 → 129 |
So under maximum sustained compute the GPU is held precisely at enforced.power.limit by sw_power_cap, with no thermal throttle of any kind and a fan curve that has plenty of room to spin up further. The bottleneck is purely the static 80 W NVPCF-default cap; the platform clearly has the thermal envelope to honour the firmware-advertised dynamic ceiling (DATP=0x168, i.e. up to ~36 W above ATPP=0xF0).
Secondary issue: missing per-OEM nvidia-powerd configs
This is a separate observation that may compound the primary bug. strings /usr/bin/nvidia-powerd shows it loads per-platform XML <configuration> files (parsed via Boost property_tree) from /usr/share/nvidia/nvidia-powerd/ (referenced filenames include dlsargs.xml), and would error out with Unable to find '<configuration>' tag in XML file if any are present but malformed.
On Arch/CachyOS the nvidia-utils-beta 595.71.05-1 package (which owns /usr/bin/nvidia-powerd) does not ship that directory — pacman -Ql nvidia-utils-beta | grep -i powerd returns only the binary and the systemd unit. pacman -Qkk confirms 0 altered files, so this matches upstream packaging. Even if NPCF binding were fixed, nvidia-powerd would still fall back to defaults without OEM XMLs that NVIDIA evidently does not redistribute publicly. Suggest either (a) shipping a generic fallback XML in the public driver, or (b) documenting which OEMs are expected to provide it and where.
Why the proprietary driver is not a workaround
We tested nvidia-beta-dkms 595.71.05 (same upstream code, proprietary build) on the same kernel. The module loads but explicitly refuses Blackwell:
NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:2d19) installed in this system
requires use of the NVIDIA open kernel modules. Please install the
NVIDIA open kernel modules to support this GPU.
NVRM: RmInitAdapter failed! (0x22:0x56:1017)
NVIDIA gates Blackwell to Open in the proprietary blob's PCI ID allowlist, so Open is the only path for this GPU.
Expected vs Actual
Expected: Open module enumerates \_SB.NPCF, evaluates _DSM UUID 36b49710-2483-11e7-9598-0800200c9a66, builds the PMO, and nvidia-powerd negotiates NVPCF GET_SUPPORTED / Dynamic Boost. Power cap rises from 80 W (static) toward the firmware-advertised dynamic ceiling.
Actual: Open module does not bind NPCF when it lives at \_SB.NPCF (peer of the GPU host bridge), only when it is a child of the GPU PCIe device. nvidia-smi reports Power Management Object: N/A. Cap stays at 80 W. Dynamic Boost effectively disabled on this Blackwell HP OEM platform.
Repro
- Boot Linux on HP OMEN Slim
8D40 with linux-cachyos-nvidia-open 595.71.05 (or any 595.x Open module).
echo performance | sudo tee /sys/firmware/acpi/platform_profile
- Confirm AML state:
cat /sys/bus/acpi/devices/NVDA0820:00/status → 15
- HPCM via
hp-wmi-mediated read (or just trust the AML allowlist match above)
nvidia-smi -q | grep -A2 'Power Management Object' → N/A
journalctl -u nvidia-powerd -b → only DBus connect line; no NVPCF activity
Attachments included in this report
Captured in ~/coding/omenLinuxHub/docs/acpi-dump/:
nvidia-bug-report.log.gz — full driver/system snapshot generated by nvidia-bug-report.sh
SSDT23 (raw) + SSDT23.dsl (decompiled with iasl -d) — the NPCF device
dsdt.dat / dsdt.dsl — DSDT with NPCF external references and AML that drives HPCM
- All other ACPI tables for completeness
gpu-burn-2026-05-24.csv — 90 s sample under gpu-burn (CUDA cublas saturation). Confirms sw_power_cap=Active and 80 W flat, with no thermal throttle of any kind.
Happy to test patches. The board is reproducible and I can also test against newer kernel/driver combos as they become available.
— Otoniel Matute (@Otogr28)
Blackwell laptop: NPCF (
NVDA0820) at\_SB.NPCFnot bound — Dynamic Boost / NVPCF inactive on HP OMEN Slim 16t-an000 (board8D40)Summary
On an HP OMEN Slim 16t-an000 (DMI board
8D40, RTX 5060 Laptop, BIOS F.13), the NVIDIA Open kernel module 595.71.05 (Blackwell-capable) does not bind the platform-side NVPCF device (Device(NPCF),_HID="NVDA0820") that lives at\_SB.NPCFrather than as a PCIe child of the GPU. Result:nvidia-smi -qreportsPower Management Object: N/Anvidia-powerdconnects D-Bus and then sits silent (no NVPCF negotiation)power.max_limitis 90 W,enforced.power.limitis 80 W — the firmware-default static caprequires use of the NVIDIA open kernel modules(RmInitAdapter failed! (0x22:0x56:1017))The firmware is correct. The HP
hp-wmidriver writesHPCM(EC offset0x95) into the firmware allowlist onplatform_profile=performance. The chain breaks inside the Open module: it never builds the PMO for an NPCF device that is not a PCIe child of the GPU.System
8D4010de:2d19)98.06.2A.80.767.0.9-1-cachyos(LTO Clang)linux-cachyos-nvidia-open595.71.05 (GSP firmware:gsp_ga10x.bin,gsp_tu10x.bin+ embedded Blackwell)nvidia-utils-betaFirmware evidence (ACPI)
Device(NPCF)is defined inSSDT23at\_SB.NPCF(not as a child of\_SB.PC00.RP12.PXSX). Extract from decompiledSSDT23.dsl:DSDT external references confirm NPCF fields are used by AML elsewhere (
ATPP,DATP,CTGP,DBAC,DBDC,DTGP,ACBT,AMAT,AMIT,PABS).ACPI device shows up in sysfs:
HPCMis updated by the in-treehp-wmidriver viaGM1A(HP WMI cmd0x1A). Empirical mapping on this board after applying the8D40patch (CachyOS issue #157):platform_profileHPCMvaluelow-power0x30balanced0x30performance0x31So in
performancethe AML allowlist check (HPCM ∈ {0x04, 0x11, 0x14, 0x21, 0x24, 0x31, 0x34}) is satisfied and_DSMsub-func 2 of NPCF returnsATPP=DATP.Userspace evidence
nvidia-smisnapshot, idle (clean boot, no workload):Power Management Object: N/A— the PMO is not built.nvidia-smi -pl 90(or any value) rejects:…because in the NVPCF model the cap is owned by the platform.
nvidia-powerdjournal across a full session (fresh boot, with__RM_ENABLE_VERBOSE_OUTPUT=1exported via a systemd drop-in):Nothing else. No NVPCF init, no error, no fallback warning. The daemon does not emit the strings present in its binary (
SBIOS support not found for NVPCF GET_SUPPORTED function,Intel NVPCF failed,Power monitor not supported on this platform. Using fallback configuration.,Error in getting the NvPCF static configuration) — it appears to never reach the code paths that would produce them. (__RM_ENABLE_VERBOSE_OUTPUT=1is confirmed set in/proc/$(pgrep nvidia-powerd)/environbut produces no additional output in 595.71.05.)Stress evidence: the cap is software, not thermal
To rule out that the 80 W ceiling is thermal, we ran
gpu-burn 90(CUDAcublasGemmExsaturation) and samplednvidia-smiandhp-wmihwmon every 2 s. Stable-state results:power.drawenforced.power.limit=80W)clocks_event_reasons.sw_power_capclocks_event_reasons.sw_thermal_slowdownclocks_event_reasons.hw_thermal_slowdownclocks_event_reasons.hw_power_brake_slowdownutilization.gpuclocks.current.graphicstemperature.gpufan1/fan2)pwm1120 → 129So under maximum sustained compute the GPU is held precisely at
enforced.power.limitbysw_power_cap, with no thermal throttle of any kind and a fan curve that has plenty of room to spin up further. The bottleneck is purely the static 80 W NVPCF-default cap; the platform clearly has the thermal envelope to honour the firmware-advertised dynamic ceiling (DATP=0x168, i.e. up to ~36 W aboveATPP=0xF0).Secondary issue: missing per-OEM
nvidia-powerdconfigsThis is a separate observation that may compound the primary bug.
strings /usr/bin/nvidia-powerdshows it loads per-platform XML<configuration>files (parsed via Boostproperty_tree) from/usr/share/nvidia/nvidia-powerd/(referenced filenames includedlsargs.xml), and would error out withUnable to find '<configuration>' tag in XML fileif any are present but malformed.On Arch/CachyOS the
nvidia-utils-beta595.71.05-1 package (which owns/usr/bin/nvidia-powerd) does not ship that directory —pacman -Ql nvidia-utils-beta | grep -i powerdreturns only the binary and the systemd unit.pacman -Qkkconfirms 0 altered files, so this matches upstream packaging. Even if NPCF binding were fixed,nvidia-powerdwould still fall back to defaults without OEM XMLs that NVIDIA evidently does not redistribute publicly. Suggest either (a) shipping a generic fallback XML in the public driver, or (b) documenting which OEMs are expected to provide it and where.Why the proprietary driver is not a workaround
We tested
nvidia-beta-dkms 595.71.05(same upstream code, proprietary build) on the same kernel. The module loads but explicitly refuses Blackwell:NVIDIA gates Blackwell to Open in the proprietary blob's PCI ID allowlist, so Open is the only path for this GPU.
Expected vs Actual
Expected: Open module enumerates
\_SB.NPCF, evaluates_DSMUUID36b49710-2483-11e7-9598-0800200c9a66, builds the PMO, andnvidia-powerdnegotiates NVPCF GET_SUPPORTED / Dynamic Boost. Power cap rises from 80 W (static) toward the firmware-advertised dynamic ceiling.Actual: Open module does not bind NPCF when it lives at
\_SB.NPCF(peer of the GPU host bridge), only when it is a child of the GPU PCIe device.nvidia-smireportsPower Management Object: N/A. Cap stays at 80 W. Dynamic Boost effectively disabled on this Blackwell HP OEM platform.Repro
8D40withlinux-cachyos-nvidia-open 595.71.05(or any 595.x Open module).echo performance | sudo tee /sys/firmware/acpi/platform_profilecat /sys/bus/acpi/devices/NVDA0820:00/status→15hp-wmi-mediated read (or just trust the AML allowlist match above)nvidia-smi -q | grep -A2 'Power Management Object'→N/Ajournalctl -u nvidia-powerd -b→ only DBus connect line; no NVPCF activityAttachments included in this report
Captured in
~/coding/omenLinuxHub/docs/acpi-dump/:nvidia-bug-report.log.gz— full driver/system snapshot generated bynvidia-bug-report.shSSDT23(raw) +SSDT23.dsl(decompiled withiasl -d) — the NPCF devicedsdt.dat/dsdt.dsl— DSDT with NPCF external references and AML that drives HPCMgpu-burn-2026-05-24.csv— 90 s sample undergpu-burn(CUDA cublas saturation). Confirmssw_power_cap=Activeand 80 W flat, with no thermal throttle of any kind.Happy to test patches. The board is reproducible and I can also test against newer kernel/driver combos as they become available.
— Otoniel Matute (@Otogr28)