The issue persists on Fedora 40 with driver version 560.35.03. However, on the Windows side, the issue has been resolved after updating the driver to version 560.
any updates to this? or can we perhaps get a way to debug it incase its a running service/application that keeps it awake?
After more than two years still broken. The fact that this works on the previous versions of the driver on Linux and that it was fixed on Windows after it was broken for some time indicates that this is a driver issue and not a Razer issue. No one seems to care from nvidia.
We need a fix for this issue, the bug is corrected for windows, not for linux.
I reproduced this on a Razer Blade 14 (RZ09-0370, RTX 3080 Mobile, BIOS 1.08) running Fedora 44, kernel 7.1.12, NVIDIA driver 610.57.04.
On AC, the dGPU remains in D3cold. On battery, it repeatedly wakes from D3cold approximately every 24 seconds and remains active for about 20–22 seconds. The captured call chain is:
rm_acpi_nvpcf_notify
→ nv_indicate_not_idle
→ pci_device_shutdown
→ __pm_runtime_resume
→ rpm_resume
The firmware source is EC query 0x34, which evaluates DSDT method _Q34. That method updates platform thermal/power data and sends:
Notify (NPCF, 0xC0)
The NVIDIA Linux driver handles this notification by taking a dynamic-power reference, waking the suspended GPU, and then allowing it to suspend again. Nouveau does not exhibit the problem.
Workaround: I disassembled the DSDT, commented out only the Notify(NPCF, 0xC0) call inside _Q34, incremented the DSDT OEM revision, compiled it, and loaded it as an initrd ACPI override using dracut. The dGPU now remains in D3cold on battery.
I have tested USB-C docking/undocking, suspend/resume via lid close, Blender using the dGPU, and NVIDIA Powermizer changes. All worked normally so far.
Potential side effect: suppressing the notification may delay NVIDIA’s rereading of firmware thermal/power-limit changes. A driver-side fix that defers NVPCF notifications until the next runtime resume would be preferable.