Periodic ACPI NVPCF notifications runtime-resume GB205 laptop GPU from D3cold

[awalterwiley]

NVIDIA Open GPU Kernel Modules Version

610.57.04 (nvidia-open-dkms 610.57.04-1)

Proprietary-driver comparison

Not applicable: this is a Blackwell GB205 laptop GPU, which requires the open
kernel modules. A same-version proprietary-kernel-module comparison is not
available.

Operating System and Version

Omarchy 4.0.0-1 (Arch Linux based)

Kernel Release

Linux zeph 7.1.8-arch1-3 #1 SMP PREEMPT_DYNAMIC Tue, 11 Aug 2026 09:16:08 +0000 x86_64 GNU/Linux

This is a stable, non-RC Arch kernel.

Hardware

• Laptop: ASUS ROG Zephyrus G14 GU405AR
• BIOS: GU405AR.302
• iGPU: Intel Panther Lake (xe, PCI 8086:b0a0)
• dGPU: NVIDIA GeForce RTX 5070 Ti Laptop GPU / GB205
• dGPU PCI functions: 10de:2f58 at 0000:01:00.0, HDA 10de:2f80 at 0000:01:00.1
• Graphics mode: Hybrid/PRIME; Intel drives the internal display

Describe the bug

While running on battery, ACPI notifications delivered through the NVIDIA
platform device at \_SB.NPCF periodically runtime-resume an otherwise idle
RTX 5070 Ti from D3cold. The resume path is inside the NVIDIA open module's
ACPI notification handling, not a userspace GPU query.

Both NVIDIA PCI functions normally remain runtime_status=suspended and
power_state=D3cold. PRIME offload works, and the GPU returns to D3cold about
25 seconds after a workload exits. Nevertheless, a kernel ftrace kprobe on
nv_pmops_runtime_resume captured the following spontaneous resume:

kworker/10:2-271 [010] .....: g14_nv_resume: (nv_pmops_runtime_resume+0x4/0x70 [nvidia])
 <stack trace>
 => kprobe_trace_func
 => kprobe_dispatcher
 => kprobe_ftrace_handler
 => crypto_ccm_module_init
 => nv_pmops_runtime_resume
 => __rpm_callback
 => rpm_callback
 => rpm_resume
 => __pm_runtime_resume
 => pci_device_shutdown
 => nv_indicate_not_idle
 => os_ref_dynamic_power
 => RmUnixRmApiPrologue
 => rm_acpi_notify
 => acpi_ev_notify_dispatch
 => acpi_os_execute_deferred
 => process_one_work
 => worker_thread
 => kthread
 => ret_from_fork
 => ret_from_fork_asm

The platform device is present and functional:

$ cat /sys/bus/acpi/devices/NVDA0820:00/path
\_SB_.NPCF
$ cat /sys/bus/acpi/devices/NVDA0820:00/status
15

A controlled ten-minute battery run at 60 Hz and power-saver, without
nvidia-smi, NVML monitors, or user interaction, recorded three wake cycles:

11:32:51 Enabling HDA controller
11:36:03 Enabling HDA controller
11:39:49 Enabling HDA controller

Each cycle kept the GPU in D0 for roughly 20–25 seconds. Whole-laptop draw rose
from a D3cold median of 9.20 W to approximately 15–19 W during those cycles.
The full-run median was 9.30 W, but the wakeups raised the mean to 11.00 W.

This appears to be the same ACPI/NVPCF wake path reported in #860, now
reproduced on GB205 with 610.57.04. It may also be related to the Blackwell
\_SB.NPCF integration problems in #1162, although that issue primarily
describes Dynamic Boost/PMO construction rather than periodic RTD3 wakeups.

To Reproduce

1. Boot the GU405AR in Hybrid mode on battery with NVIDIA open 610.57.04.
2. Keep both functions runtime-managed:
   power/control=auto for 0000:01:00.0 and 0000:01:00.1.
3. Close all explicit NVIDIA workloads and wait until both functions report
   runtime_status=suspended and power_state=D3cold.
4. Do not run nvidia-smi, NVML-based widgets, nvtop, or repeated PCI config
   probes.
5. Trace nv_pmops_runtime_resume and wait. A firmware notification reaches
   rm_acpi_notify, calls os_ref_dynamic_power, and resumes the GPU.
6. The GPU returns to D3cold after the transient, then repeats the cycle a few
   minutes later.

The issue reproduced three times during one ten-minute measurement and again
within 50 seconds during a separate bounded ftrace capture.

Bug incidence

Always on battery during the observed tests; timing is periodic but not fixed.

Expected behavior

An ACPI/NVPCF notification that does not require GPU work should not take a
runtime-suspended GPU out of D3cold. The driver should avoid acquiring a
dynamic-power reference when the notification can be handled or rejected
without powering the GPU.

Additional information

• NVreg_DynamicPowerManagement=3 resolves to fine-grained RTD3.
• nvidia-persistenced is inactive.
• nvidia-powerd is active, but it does not prevent D3cold; it logs that SBIOS
  requested disabling the Dynamic Boost DC controller.
• The NVIDIA HDA function also reaches D3cold.
• The internal display and desktop renderer are Intel/Xe.
• No ACPI-table override or driver parameter workaround has been applied.

nvidia-bug-report.log.gz

Generated immediately after reproduction:

nvidia-bug-report-g14-nvpcf.log.gz

SHA-256:
19646df16707c9c966ca3ee47c4de9e928873895ea53f63e1ac20fa9685fa9da

[lars76]

This is related to my PR #1299. On my machine (GA403UI) the per-1% battery tick arrives via the _SB.NPCF platform device. Your stack shows the wake entering through rm_acpi_notify, a notification on the GPU's own ACPI device, which #1299 intentionally leaves untouched. So #1299 alone will probably not stop your wakes.

#1181 also guards that handler and would likely silence your wakes, but it drops the notification. The notification tells the driver to read new settings from the firmware (for example a new GPU temperature target). If it is dropped, the driver keeps the old settings, because nothing re-reads them later. The safer solution is probably to extend the defer-and-replay pattern from #1299 to this handler as well. I have not done that because my machine only reproduces the NPCF path, so I could not test it.

On my laptop these wakes cost about 20% of battery runtime, and judging by #860, #905 and #1201 the same thing hits a lot of hybrid laptops. That is why I ended up fixing it myself in the way that made most sense to me. Where the fix should finally live is of course NVIDIA's call.