Hello NVIDIA Linux / PowerD developers,
We have isolated a reproducible NVIDIA PowerD 2.0 JPAC controller lifecycle failure on an ASUS TUF Gaming A15 FA506NCR.
System:
- ASUS FA506NCR, BIOS 306
- AMD Ryzen 7 7435HS
- NVIDIA RTX 3050 Laptop GPU
- Debian 13, kernel 7.2.6+deb13-amd64
- NVIDIA driver 615.71.09, nvidia-powerd 2.0
Observed errors:
DC power limits table is not supported
Failed to get SysPwrLimitGetInfo!!
Client (presumably SBIOS) has requested to disable Dynamic Boost DC controller
CRITICAL! Failed to get SysPwrLimitGetInfo
JPAC is not created/already destroyed, ignoring request.
The last JPAC message repeats continuously.
Native tracing evidence:
Using bounded tracefs uprobes on the unmodified nvidia-powerd executable, we confirmed:
1. The JPAC controller is successfully allocated.
2. Two “std::runtime_error” exceptions occur in “SysPwrLimitGetInfo” paths, at call sites “0x41e79b” and “0x41e6c1”.
3. Exception handling at “0x41ad6e” destroys the allocated controller.
4. Subsequent JPAC requests continue with a null controller pointer while the enable flags remain set.
Firmware observations:
ASUS NVPCF version “0x23” reports AC Dynamic Boost enabled and DC disabled (“PC02=2”).
The examined BIOS ACPI tables do not implement “_DSM” function 8 for DC system power limits. Function 0 can conditionally advertise this capability depending on EC state.
The exact failing RM/ACPI request has not yet been captured. Therefore, a firmware capability mismatch remains a hypothesis rather than a proven root cause.
Important: AC Dynamic Boost works.
During Rocket League gameplay on October 12, 2026, the GPU’s active power ceiling increased from the 60 W default to 63.42 W, with a reported maximum of 75 W.
This confirms dynamic AC power-limit adjustment, not sustained 63.42 W consumption.
Questions for NVIDIA engineers:
1. Should unsupported DC system power limits cause JPAC controller destruction when DC Dynamic Boost is disabled?
2. Can PowerD recover from this failure without generating repeated null-controller requests?
3. Is there a known fix in a newer driver or PowerD release?
4. What additional read-only tracing would help isolate the failing RM/firmware handshake?
We have detailed native traces and ACPI analysis available upon request, with private system information removed.
We would appreciate technical guidance from NVIDIA PowerD developers or anyone familiar with the NVPCF protocol.
Thank you,
Dr. Stacktrace
Tux Lab Engineering