You are not logged in.
When installing the Nvidia Optimus drivers for nvidia only graphics, my machine started draining all its battery life in ~4 hours during suspend (this is my normal battery life when using the laptop). The laptop is also producing heat in suspend, though not much.
I've verified that the machine is put to an S3 state during sleep:
sudo journalctl | grep "PM: suspend" | tail showing (deep) for all suspends.
Contents of
/sys/power/mem_sleep is also as it should be:
s2idle [deep] I've seen a lot of threads where the issue has been fixed by installing TLP and/or bbswitch. I have TLP installed, and it did not make any difference. Since I'm not using bumblebee, I assumed bbswitch wouldn't do much - and I was right.
This is definitely not a hardware or firmware issue, sleeping in Windows works as it should.
I should also mention that I experienced the same thing when using bumblebee for running on integrated graphics, and using intel-virtual-output for external displays (HDMI is wired directly to Nvidia GPU), but I quickly switched to Nvidia only due to performance issues.
As is quite obvious, I suspect that the GPU is not being powered down during suspend/sleep. Any way to verify this or solve the problem? I have not tested this for hibernate to disk since it is not really a valid solution for me. I need my suspends.
Thanks
Last edited by vegarab (2019-09-07 11:07:06)
Offline
Which kernel are you on? You can check using "uname -r".
EDIT: Are you using your dGPU? If so are you remembering to turn it off before suspending?
Last edited by rhysperry111 (2019-09-05 18:59:35)
Offline
I'm using 5.2.9 at the moment.
Yes, everything runs on the dGPU. I'm not sure how I would go about turning it off/on for suspend.
Offline
You might want to check for BIOS/UEFI firmware updates as those are the most likely case for fixes in that regard.
Something you can try is enable the new systemd power management integration services.
Offline
Might attempt a BIOS upgrade. I should do so anyways due to a huge issue with the default BIOS version on my laptop with regards to switching between dGPU and iGPU. I've already completely bricked my machine by doing that..
Edit: but as mentioned, everything works perfectly fine when sleeping in Windows - and did work fine until I changed my GPU setup in arch
That systemd feature really looks like what I need. Will take a look, thanks.Go
Last edited by vegarab (2019-09-06 09:59:59)
Offline
/sys/power/mem_sleep s2idle [deep]
That's target. Does it actually sleep deep?
systemctl suspend
journalctl | grep "PM: suspend"Last edited by sabroad (2019-09-06 10:02:04)
--
saint_abroad
Offline
Yes, as I mentioned in my post the output there shows "(deep)" on all suspends.
Offline
Yes, as I mentioned in my post the output there shows "(deep)" on all suspends.
Sorry, indeed you did.
external displays (HDMI is wired directly to Nvidia GPU)
Does the battery drain on sleep also happen without HDMI plugged in during suspend?
This is definitely not a hardware or firmware issue, sleeping in Windows works as it should.
Could be a driver issue. Does it drain if you unload the nvidia module prior to suspend?
--
saint_abroad
Offline
Firmware issues that trip one operating system and work fine on another are definitely possible and imo this would be the first thing to try, with the least possible custom config/workarounds involved.
Last edited by V1del (2019-09-06 10:49:04)
Offline
Firmware issues that trip one operating system and work fine on another are definitely possible and imo this would be the first thing to try, with the least possible custom config/workarounds involved.
Alright, I will definitely do this then. I have never done a BIOS upgrade before, do you have any pointers?
I also enabled the systemd power management integration service. Will check tonight if it solved the issue.
--
I should mention that this seems like a symptom of my GPU struggles. I've made a few posts earlier regarding use of dGPU and iGPU on my specific laptop (X1 Extreme gen2 with 1050TI Max-Q). My issues earlier when only running CPU (when battery life was fine), was that I could not get any of my external video ports to work (HDMI is wired to dGPU). My first attempt to fix this was using bumblebee/bbswitch and intel-virtual-output for external displays. This was not a great experience, since optirun/primusrun gave really poor performance in 3D intensive applications, and the external screens had a lot of tearing and performance issues. I also had issues with power drain in suspend with this setup, but it was not as bad as it is right now.
I've read that optimus-manager might be a pretty good solution, only requiring a new Xorg session for switching graphics. On my laptop's wiki page https://wiki.archlinux.org/index.php/Le … me_(Gen_2) however, it says that bbswitch is not supported and that the new beta feature for Prime offloading in the NVIDIA drivers does not work with external displays at all. I am generally very confused with regards to the GPU-configs on Optimus laptops.
All I want is to be able to use external displays seamlessly, use my GPU for CUDA acceleration and some 3D applications and not have my laptop die during suspend.
Offline
Optimus-manager does not do anything you wouldn't already be doing right now. If compatibility and max performance with the hardwired screen is your concern you will have to "logically" remain on the setup you have now. (You could install optimus-manager so that the switching is "easier" should you be on the go, however since it's unlikely that you want to discard all of your work (which is why you are suspending and not shutting down I'd assume...) there's not much that it would help you with. (Optimus manager does the same exact thing you are doing now, it simply provides a simple means of quickly shutting down xorg, rewritting config files for the adapter wanted and restarting xorg on the intel only, or nvidia over intel combo.)
Regarding the BIOS update, that will be different from vendor to vendor, one thing you might have to be weary of, is that there's a chance that they will discard any stored NVRAM entries, in which case you might have to reinstall your EFI bootloader. Also - afaik though I don't use them myself - Lenovo has added some firmware option to (some?) lapotp models - specifically for suspension - to switch between a linux or Windows compatible modes, if your laptop happens to benefit/ be affected from these might also make a difference here.
Last edited by V1del (2019-09-06 11:41:18)
Offline
Thank you for the input here. I think I will use my Windows installation to perform the BIOS update - it seems Lenovo supports that better.. Reinstalling GRUB is fine.
Do you have any resources for those firmware options? Never heard of them myself.
Offline
Enabling the systemd power management integration services solved the issue completely. Wen't from >100% drain to 2% over a period of 8 hours.
Offline