Battery draining fast on my Acer Predator Helios 300 (Zorin 18.1) — here's what worked for me
Sharing this in case it helps someone else. Short version: my NVIDIA GPU was never actually powering off, and disabling something called GSP firmware fixed it. Idle draw went from 25.7W down to 15.2W — roughly 1.5 hours of battery to about 2.4. If you have a GTX 16xx or RTX 20xx laptop, this might apply to you too, whatever brand it is.
What I was seeing
I recently installed Zorin OS 18.1 on my Acer Predator Helios 300 (PH315-53, RTX 2060 Mobile). Everything worked well except battery life — noticeably worse than Windows on the same machine. Around an hour and a half of light use.
I'd already installed TLP, PRIME was in on-demand mode, drivers were installed properly. On paper everything was configured correctly, and it was still pulling ~25W just sitting idle.
Turned out the discrete GPU was awake the entire time. It showed as "idle" at 3W in nvidia-smi, but idle isn't the same as off — it was never actually powering down. Windows puts the same card into D3 when idle, so I knew the hardware could do it.
The command that made it obvious:
cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_suspended_time
That's a counter of how long the GPU has spent suspended. Mine said 0. It had never slept, not once, since boot.
My setup
- Acer Predator Helios 300 PH315-53, BIOS V2.04 (latest available for my unit)
- Intel i7-10750H + Intel UHD graphics
- NVIDIA RTX 2060 Mobile — Turing generation, which turns out to be the key detail
- Zorin OS 18.1, GNOME 46, kernel 7.0.0-28, driver 595.84
- Wayland session, PRIME
on-demand
How to tell if you have the same problem
Run this:
cat /proc/driver/nvidia/gpus/0000:01:00.0/power
If the first line says Runtime D3 status: Not supported, your GPU probably isn't sleeping either.
(If your GPU is at a different PCI address, lspci | grep -i nvidia will show you — swap it into the command.)
You're likely affected if you have a hybrid laptop with a Turing dGPU — GTX 1650, 1660, RTX 2050 through 2080, and their mobile variants.
If you have an RTX 30xx, 40xx or newer, this probably isn't your issue. Those handle it properly. If yours already says Enabled (fine-grained), there's nothing to fix here.
What was actually causing it
I went down a lot of wrong paths before finding this (list at the bottom, in case it saves you the time).
The cause is something called GSP firmware. Newer NVIDIA drivers offload power management and other work to a small processor inside the GPU itself, rather than handling it in the driver. It's enabled by default and it's also what makes NVIDIA's open-source kernel module possible.
On Turing cards — the first generation to have it — that firmware appears to be buggy and prevents runtime power management from working at all. The driver checks, the check fails, and it just reports "Not supported" no matter how correctly everything else is set up.
I found this documented in a few places once I knew what to search for:
- A Fedora Discussion thread titled "[HEADS-UP] Nvidia proprietary driver with Open kernel and GSP firmware breaks Runtime D3 on Turing cards"
- NVIDIA's own GitHub, issue #640 on open-gpu-kernel-modules — "D3cold on Turing Mobile not working... Works with closed driver"
- The ArchWiki NVIDIA page, which mentions GSP causing issues and suggests the proprietary driver with the firmware disabled
What worked for me
One catch first: the open kernel module requires GSP, so you can't disable it there. You need the proprietary driver.
1. Check which driver you're on
lsmod | grep nvidia
If the nvidia module is around 15MB you're on the open one. Around 100MB means proprietary. If you need to switch:
sudo apt install nvidia-driver-595
Use whatever version applies to you — ubuntu-drivers devices shows what's recommended for your card.
2. Add the module options
sudo nano /etc/modprobe.d/nvidia-pm.conf
Paste these two lines:
options nvidia NVreg_EnableGpuFirmware=0
options nvidia NVreg_DynamicPowerManagement=0x02
Save with Ctrl+O, Enter, Ctrl+X.
One thing worth flagging: use 0x02 if you have a Turing card. A lot of guides out there say 0x03, but that's for Ampere and newer — on an older card it can turn power management off entirely. This tripped me up while reading around.
3. Rebuild initramfs and reboot
sudo update-initramfs -u
sudo reboot
4. Check whether it worked
cat /proc/driver/nvidia/gpus/0000:01:00.0/power
Mine now says:
Runtime D3 status: Enabled (fine-grained)
Video Memory: Off
GPU Hardware Support:
Video Memory Self Refresh: Supported
Video Memory Off: Supported
Video Memory: Off means the GPU is powered down right at that moment, while the driver is still loaded and ready.
And the counter that was stuck at zero is now climbing:
cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_suspended_time
To see the actual difference, unplug and run:
upower -i $(upower -e | grep BAT) | grep -E "energy-rate|time to empty"
5. Make sure you can still use the GPU
Zorin doesn't come with prime-run, so I made one:
sudo tee /usr/local/bin/prime-run > /dev/null << 'EOF'
#!/bin/bash
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia __VK_LAYER_NV_optimus=NVIDIA_only "$@"
EOF
sudo chmod +x /usr/local/bin/prime-run
Test that the GPU still wakes up when something needs it:
sudo apt install mesa-utils
prime-run glxinfo | grep "OpenGL renderer"
That reported my RTX 2060, and half a minute later the GPU was back asleep. For Steam games, prime-run %command% as a launch option.
How to undo it if it doesn't help you
Nothing here touches your firmware, partitions or bootloader. To reverse everything:
sudo rm /etc/modprobe.d/nvidia-pm.conf
sudo rm /usr/local/bin/prime-run
sudo update-initramfs -u
sudo reboot
To go back to the open kernel module as well:
sudo apt install nvidia-driver-595-open
sudo update-initramfs -u
sudo reboot
If you end up without a working desktop (a bad module option can do this): press Ctrl+Alt+F3 for a text console, log in, and run the removal commands above. If that doesn't come up, hold Shift during boot for the GRUB menu → Advanced options → recovery mode → root shell (you may need mount -o remount,rw / first).
The whole thing only creates two files — /etc/modprobe.d/nvidia-pm.conf and /usr/local/bin/prime-run.
Trade-offs I accepted
Being upfront about these:
- You're stuck with the proprietary driver. The open module needs GSP. Didn't bother me.
- This is a legacy path. NVIDIA is moving toward GSP everywhere, so if they eventually remove the non-GSP option this stops working. That's the main long-term risk.
- Slightly more CPU work, since the driver does what GSP would have handled. Not something I can notice.
Gaming performance, stability and CUDA all seem unaffected — if anything the non-GSP path is the older, more tested one on Turing.
One thing to watch: if your battery life quietly gets worse after a driver update, check grep -i gpufirmware /proc/driver/nvidia/params. If it says 1, the update overrode your setting.
Things I tried that did NOT work
Sharing these so you don't repeat them — I spent hours here:
- Switching between Wayland and X11. On Wayland
gnome-shellholds the GPU device open; on X11,Xorgdoes. I thought this was the cause for a long time, but it isn't — fine-grained power management is designed to suspend even with clients attached. - The
mutter-device-preferred-primaryudev rule. It controls which GPU composites your desktop, but doesn't stop the other one being opened. - Deleting
/usr/share/X11/xorg.conf.d/11-nvidia-offload.conf. No effect, andgpu-managerjust recreates it on every boot. - udev rules to remove the GPU's audio and USB-C functions. These do get removed, but the verdict didn't change — and you lose HDMI audio for nothing.
- Swapping between open and proprietary drivers on its own. Both said "Not supported" while GSP was still enabled. The swap only matters because it lets you disable GSP.
- Looking for a BIOS update. V2.04 is the last one Acer released for my model.
dmesg | grep _PR3to check ACPI power resource support. This is not a reliable test — it gave me a false negative and I wrongly concluded my laptop's firmware didn't support the feature at all. If you want to check properly, look atls /sys/bus/pci/devices/0000:00:01.0/firmware_node/forpower_resources_D3hot, and search the SSDT tables rather than just the DSDT.
Other things that helped a bit
Once the GPU was sorted, the rest is mostly screen and CPU:
In /etc/tlp.conf:
CPU_ENERGY_PERF_POLICY_ON_BAT=power
CPU_BOOST_ON_BAT=0
CPU_MAX_PERF_ON_BAT=60
PLATFORM_PROFILE_ON_BAT=low-power
then sudo tlp start.
Also worth dropping the refresh rate from 144Hz to 60Hz when on battery, and turning brightness down — both are worth a few watts. GNOME won't switch refresh rate automatically so it's a manual change in Settings → Displays.
Hope this helps someone. I'd almost accepted bad battery life as just the cost of running Linux on a gaming laptop, so I'm glad I kept digging. If you've got a Turing laptop, that runtime_suspended_time check takes ten seconds and is worth running — I suspect a lot of people have this without realising.