Nvidia on Hybrid laptops while on battery goes to D0 state randomly wasting battery life

[stoneflesh0]

I have spent too much time trying to figure out, why does my nvidia gpu keep waking up when nothing is triggering it when on battery. When the laptop is plugged in to power, it doesn't randomly wake up the Nvidia GPU.

How to reproduce:

1. Nvidia-open installed
2. unplug charger
3. wait
4. notice the nvidia gpu waking from d3cold into d0 after 15 seconds (?) it goes to d3cold
5. wait (for 1-2minutes)
6. nvidia wakes up and repeats the pattern

The Nvidia DGPU also always wakes up when charger is plugged in or removed and when power profile is changed. Maybe these are all related?

I really care to have this fixed. As I have two laptops (G16 with rtx4080 and G14 with rtx4060) and both laptops have this issue.

I have accidentally found this issue #860 Maybe this is the issue as others also complain about the same. There is no solution provided. Is it possible to get this solved?

OS: CachyOS x86_64
Host: ROG Zephyrus G16 GU605MZ_GU605MZ (1.0)
Kernel: Linux 7.0.11-1-cachyos
Uptime: 8 hours, 47 mins
Display (SDC41A3): 2560x1600 @ 1.75x in 16", 60 Hz [Built-in]
DE: KDE Plasma 6.6.5
WM: KWin (X11)
CPU: Intel(R) Core(TM) Ultra 9 185H (22) @ 5.10 GHz
GPU 1: NVIDIA GeForce RTX 4080 Max-Q / Mobile [Discrete]
GPU 2: Intel Arc Graphics @ 2.35 GHz [Integrated]
Memory: 10.89 GiB / 30.75 GiB (35%)

[lars76]

I reproduced the periodic wakes on a Zephyrus G14 (GA403UI, RTX 4070): the firmware's NVPCF battery notification wakes the suspended GPU for ~20 s each time. I submitted a fix that defers the notification until the GPU next resumes instead of waking it. See #1299 (#1181 is an alternative that drops the notifications instead).

[SokolDmytro]

OS: NixOS 26.05 (Yarara) x86_64
Host: ROG Zephyrus G16 GA605WI_GA605WI (1.0)
Kernel: Linux 7.1.13
Uptime: 12 mins
Packages: 1566 (nix-system)
Shell: bash 5.3.9
Display (SDC41AE): 2560x1600 @ 1.67x in 16", 240 Hz [Built-in]
DE: GNOME 50.4
WM: Mutter (Wayland)
WM Theme: Adwaita
Theme: Adwaita [GTK2/3/4]
Icons: Adwaita [GTK2/3/4]
Font: Liberation Sans (10pt) [GTK2/3/4]
Cursor: Adwaita (24px)
Terminal: tmux 3.6a
CPU: AMD Ryzen AI 9 HX 370 (24) @ 2.00 GHz
GPU 1: AMD Radeon 890M Graphics [Integrated]
GPU 2: NVIDIA GeForce RTX 4070 Max-Q / Mobile [Discrete]
Memory: 8.31 GiB / 30.44 GiB (27%)
Swap: 176.00 KiB / 15.22 GiB (0%)
Disk (/): 286.75 MiB / 547.03 GiB (0%) - zfs
Battery (A32-K55): 56% (4 hours, 8 mins remaining) [Discharging]

Root cause and a firmware-level workaround for the battery-triggered dGPU wakeups (NVPCF)

Same symptom as #860 and as this discussion: on battery the dGPU leaves D3cold roughly
once per percent of charge, stays in D0 for ~20 s, then goes back to sleep. On AC it never
happens. I traced it end to end and found a workaround that removes it completely on my
machine, at the ACPI level.

System

• ASUS ROG Zephyrus (AMD Radeon 890M iGPU + RTX 4070 Laptop dGPU)
• NixOS, kernel 7.1.13
• Runtime D3 status: Enabled (fine-grained), Video Memory: Off
• nvidia-powerd is not installed at all — Dynamic Boost is not in use on this system

That last point matters: the GPU is being woken up to service a subsystem the machine
does not use.

Step 1 — it is not userspace

bpftrace on openat for every nvidia node and for the GPU's sysfs directory shows
nothing at the moment of the wakeup. The only opener is a monitoring daemon reading
/sys/bus/pci/devices/<addr>/power_state, which is cached by the PM core and does not
resume the device.

Step 2 — the kernel says who resumes it

sudo bpftrace -e 'kprobe:pci_pm_runtime_resume { printf("%s pid=%d\n", comm, pid); print(kstack); }'

kworker/15:2     pid=13793

        pci_pm_runtime_resume+5
        __rpm_callback+72
        rpm_callback+109
        rpm_resume+1209
        __pm_runtime_resume+82
        pci_device_shutdown+27
        nv_indicate_not_idle+46
        _nv046433rm+276
        rm_acpi_nvpcf_notify+155
        acpi_ev_notify_dispatch+78
        acpi_os_execute_deferred+26
        process_one_work+409
        worker_thread+375
        kthread+226
        ret_from_fork+593
        ret_from_fork_asm+26

Identical to the stack in #860, on a much newer kernel and driver. So the firmware sends
an ACPI Notify() to the NPCF device, the driver's rm_acpi_nvpcf_notify handler runs and
unconditionally takes a dynamic-power reference, which resumes the GPU.

Step 3 — what the firmware actually does

Dumping and disassembling the DSDT shows the exact path. The EC query handler _QB6,
which fires on battery state changes, calls STPL():

Method (_QB6, 0, NotSerialized)
{
    Sleep (0x64)
    STPL ()
}

Method (STPL, 0, NotSerialized)
{
    If ((FTBL == 0x02))
    {
        If ((RSOC < 0x32))              // RSOC = relative state of charge, i.e. battery %
        {
            ^^^^NPCF.TPPL = One
            DBDI ()                      // dynamic boost disable
        }
        Else
        {
            ^^^^NPCF.TPPL = 0x2CEC
            DBEN ()                      // dynamic boost enable
        }
    }
    ElseIf ((FTBL == Zero))
    {
        ^^^^NPCF.TPPL = 0x00017318
        ^^^^NPCF.DBDC = One
    }

    Sleep (0x64)
    Notify (NPCF, 0xC2)
    Sleep (0x64)
    Notify (NPCF, 0xC0)
}

So on every change of the charge percentage the firmware recomputes the GPU power
policy and sends two notifications to NPCF. The threshold logic itself only cares about one
boundary (50%), but the notification is sent regardless of whether anything changed.

acpi_listen confirms the trigger: battery PNP0C0A:00 00000080 00000001.

Workaround: drop the STPL call from the battery query handler

Extract the tables, disassemble, and comment out the call:

     Method (_QB6, 0, NotSerialized)
     {
-        Sleep (0x64)
-        STPL ()
+        // Sleep (0x64)
+        // STPL ()
     }

Bump the OEM revision in the header so it is obvious which table is loaded:

-DefinitionBlock ("", "DSDT", 2, "_ASUS_", "Notebook", 0x01072009)
+DefinitionBlock ("", "DSDT", 2, "_ASUS_", "Notebook", 0x0107200A)

Recompile with iasl and load it through the initrd ACPI table override
(CONFIG_ACPI_TABLE_UPGRADE), with the file at kernel/firmware/acpi/dsdt.aml inside an
uncompressed cpio archive prepended to the initrd. Confirmation in dmesg:

ACPI: DSDT ACPI table found in initrd [kernel/firmware/acpi/dsdt.aml]
ACPI: Table Upgrade: override [DSDT-_ASUS_-Notebook]
ACPI: DSDT ... (v02 _ASUS_ Notebook 0107200A INTL 20250404)

What this costs

STPL() is still called from _QD4 (platform profile change), so the "below 50% charge,
reduce TGP" policy is not removed — it just stops being applied at the exact moment the
threshold is crossed, and is applied on the next profile change instead. _QA8 and _QD4
still send Notify(NPCF, 0xC0), but neither is tied to the charge percentage, so those are
rare. Battery reporting is unaffected (upower still reports percentage, state and time
remaining correctly).

For anyone not running nvidia-powerd, the cost is effectively zero, since NPCF.TPPL,
DBAC and DBDC are only consumed by that daemon.

Caveats

This is a firmware override: it taints the kernel, has to be redone after a BIOS update,
and is obviously specific to this DSDT. It is a workaround, not a fix.

Suggested fix in the driver

The original report in #860 already pointed at it: rm_acpi_nvpcf_notify calls
os_ref_dynamic_power without checking the GPU's current runtime power state. Checking
whether the GPU is in D3cold before taking the reference — or deferring the NVPCF state
update until the GPU is resumed for some other reason — would remove the need for any
firmware patching.

It is worth stressing that on this system the wakeups happen with nvidia-powerd not
installed. The driver resumes the GPU to process notifications whose results nothing
consumes.

Related: #860 (closed with no comment and no fix).