I’m using a Dell XPS 9530 (2023) and recently installed OpenSUSE Tumbleweed on it. Since then, I’m experiencing a lot of battery drain during sleep. In about 10 hours of sleep, the battery will have drained around 50%. I’ve had other Linux distributions installed on this machine, which did not have the battery drain issue.
I found a previous post of a similar issue on the forums here, but no solution. I’m looking for some assistance to debug this issue with me.
So far, due to the nature of the extra nvidia graphics card, I found that wasn’t properly configured. The drivers were installed, but nvidia prime wasn’t configured, making my laptop run very hot. I’ve since configured it to use the “offload” functionality, meaning my intel graphics are used until I tell an application to use the nvidia card. This has significantly reduced the heat of my laptop, but sadly has had no impact on the battery drain during sleep.
The content of /sys/power/mem_sleep says [s2idle], which I think are the correct settings.
Boot params in grub:
mitigations=auto splash=silent quiet security=apparmor noresume nvidia-drm.modeset=1
I’m using the default (configured through installation) full disk encryption. Meaning I’ve got two luks partitions, one for system (btrfs) and one for swap. I’ve modified /etc/crypttab to use a keyfile instead of passphrase, since the passphrase is entered in GRUB.
Any pointers to help me debug this issue are greatly appreciated!
@jbouter Hi and welcome to the Forum 
Normally with Intel/Nvidia the kernel option is nosimplefb=1 then could also look at using the power options in a /etc/modprobe.d/50-nvidia.conf file with;
##Power Management
options nvidia NVreg_DynamicPowerManagement=0x02
Ref: https://download.nvidia.com/XFree86/Linux-x86_64/550.90.07/README/powermanagement.html
@jbouter Forgot to say if using the modprobe.d file, run dracut -f --regenerate-all after adding and before a reboot.
Hi @malcolmlewis 
! And thanks for the warm welcome 
!
I’ve updated /etc/default/grub and replaced nvidia-drm.modeset=1 with nosimplefb=1, after which I regenerated the grub config file. I’ve also created said modprobe file, and regenerated initramfs.
I’ll sleep the laptop tonight, and hope it drains less quickly! Thanks for your help so far!
Sadly, the suggestions don’t seem to have worked @malcolmlewis. The battery still drained 50% overnight.
@jbouter when you sat nvidia-prime, I’m assuming that’s suse-prime? If so, my suggestion is to remove that and any associated files and try switherooctl instead.
I do believe that bbswitch may be needed with suse-prime to turn the card off. All my experience has been with switcherooctl with Intel/Nvidia/AMD combinations.
@malcolmlewis No, I didn’t know suse-prime existed. I don’t entirely understand what you mean I should do. Uninstall nvidia-prime and install both suse-primt and switcherooctl instead?
@jbouter yes remove this nvidia-prime, skip suse-prime at this point and install switcheroo-control package and enable/start the service with systemctl enable --now switcheroo-control.service
Then as you user run switcherooctl list and should see both devices? Then can launch applications with switcherooctl.
@malcolmlewis I’ve only got prime-select and prime-run installed, which are both part of the suse-prime package. nvidia-prime is not installed on my system.
I’ve also got switcheroo-control installed by default, but the service isn’t enabled by default.
I’ve done the following:
- Remove
suse-prime
- Enable switcheroo-control:
systemctl enable --now switcheroo-control.service
- Check that
switcherooctl list does indeed list two graphics cards, which it does.
Should I reboot my machine in order to test if suspend now works better?
@jbouter yes, also check the nvidia services…
@malcolmlewis
I can see the nvidia services being called properly:
Jun 27 18:15:46 xps.local systemd[1]: Starting NVIDIA system suspend actions...
Jun 27 18:15:46 xps.local suspend[9589]: nvidia-suspend.service
Jun 27 18:15:46 xps.local logger[9589]: <13>Jun 27 18:15:46 suspend: nvidia-suspend.service
Jun 27 18:15:47 xps.local systemd[1]: nvidia-suspend.service: Deactivated successfully.
Jun 27 18:15:47 xps.local systemd[1]: Finished NVIDIA system suspend actions.
Jun 28 11:30:14 xps.local systemd[1]: Starting NVIDIA system suspend actions...
Jun 28 11:30:14 xps.local suspend[33667]: nvidia-suspend.service
Jun 28 11:30:14 xps.local logger[33667]: <13>Jun 28 11:30:14 suspend: nvidia-suspend.service
Jun 28 11:30:16 xps.local systemd[1]: nvidia-suspend.service: Deactivated successfully.
Jun 28 11:30:16 xps.local systemd[1]: Finished NVIDIA system suspend actions.
@jbouter OK, see what happens now… Oh there were no bbswitch items installed?
@malcolmlewis Thanks so far! Are you confident it has to do with the nvidia card though?
rpm -qa | grep bbswitch doesn’t yield any results.
@jbouter well just eliminating what may be keeping it powered on. The NVreg_DynamicPowerManagement=0x02 option will allow the GPU to go into its lowest power state when no applications are running that use the nvidia driver, so something else is keeping powered on…
Read more info here https://download.nvidia.com/XFree86/Linux-x86_64/555.58/README/dynamicpowermanagement.html
@malcolmlewis I read that the on the previous post where you linked it, thank you so much as it cleared up a lot. I’m afraid something else is causing the draining… could it be related to the encrypted swap partition?
On my other installations, I always had /boot on a separate unencrypted partition. In this case, only /boot/efi is unencrypted and all the rest is on an encrypted partition. During the decryption phase in GRUB (which is very slow), my laptop already heats up a lot. I reckon this has to do with no drivers being loaded yet.
@jbouter Can you post the output from inxi -GSaz to see the current boot and gpu setup.
Definitely @malcolmlewis, here you go:
System:
Kernel: 6.9.6-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.3.0
clocksource: tsc avail: acpi_pm
parameters: BOOT_IMAGE=/boot/vmlinuz-6.9.6-1-default
root=UUID=8b2b6d57-3953-4e29-877f-817bcdb2d252 mitigations=auto
splash=silent quiet security=apparmor noresume nosimplefb=1
mem_sleep_default=deep
Desktop: KDE Plasma v: 6.1.0 tk: Qt v: N/A info: frameworks v: 6.3.0
wm: kwin_wayland with: krunner tools: avail: xscreensaver vt: 3 dm: SDDM
Distro: openSUSE Tumbleweed 20240625
Graphics:
Device-1: Intel Raptor Lake-P [Iris Xe Graphics] vendor: Dell driver: i915
v: kernel alternate: xe arch: Gen-13 process: Intel 7 (10nm) built: 2022+
ports: active: eDP-1 empty: DP-1, DP-2, DP-3, DP-4, HDMI-A-1
bus-ID: 0000:00:02.0 chip-ID: 8086:a7a0 class-ID: 0300
Device-2: NVIDIA AD107M [GeForce RTX 4060 Max-Q / Mobile] vendor: Dell
driver: nvidia v: 550.90.07 alternate: nouveau,nvidia_drm non-free: 550.xx+
status: current (as of 2024-06) arch: Lovelace code: AD1xx
process: TSMC n4 (5nm) built: 2022+ bus-ID: 0000:01:00.0
chip-ID: 10de:28a0 class-ID: 0302
Device-3: Microdia Integrated_Webcam_HD driver: uvcvideo type: USB
rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 3-6:2 chip-ID: 0c45:6748
class-ID: fe01 serial: <filter>
Display: wayland server: X.org v: 1.21.1.12 with: Xwayland v: 24.1.0
compositor: kwin_wayland driver: N/A display-ID: 0
Monitor-1: eDP-1 res: 2304x1440 size: N/A modes: N/A
API: EGL v: 1.5 hw: drv: intel iris drv: nvidia platforms: device: 0
drv: nvidia device: 1 drv: iris device: 3 drv: swrast gbm: drv: iris
surfaceless: drv: nvidia wayland: drv: iris x11: drv: iris
inactive: device-2
API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: intel mesa v: 24.1.2 glx-v: 1.4
direct-render: yes renderer: Mesa Intel Graphics (RPL-P)
device-ID: 8086:a7a0 memory: 15.15 GiB unified: yes display-ID: :0.0
API: Vulkan v: 1.3.283 layers: 6 device: 0 type: integrated-gpu
name: Intel Graphics (RPL-P) driver: N/A device-ID: 8086:a7a0
surfaces: xcb,xlib,wayland device: 1 type: discrete-gpu name: NVIDIA
GeForce RTX 4060 Laptop GPU driver: N/A device-ID: 10de:28a0
surfaces: xcb,xlib,wayland
I’ve also found that deep sleep is no longer reported by the EFI/BIOS to the system, effectively making sleep much less efficient on Linux.
Because S3 support is not reported to the OS…
@jbouter I was wondering about that, but should still be valid? https://www.kernel.org/doc/Documentation/admin-guide/pm/sleep-states.rst
What does journalctl -b | grep "ACPI: PM" report?
So your sure the displaying is powering off? With my Intel ARC with i915 I set the enable_dc=0 else sometimes the screens (I have three) don’t power off, backlight still on…
I have no idea about the encryption side, might need to start a new thread on that…
So I’m guessing that TLP is installed and running? If so, maybe that needs some work?
@malcolmlewis
jbouter@xps:~$ sudo journalctl -b | grep "ACPI: PM"
Jun 28 22:02:05 xps.local kernel: ACPI: PM-Timer IO Port: 0x1808
Jun 28 22:02:05 xps.local kernel: ACPI: PM: Registering ACPI NVS region [mem 0x60d11000-0x61571fff] (8785920 bytes)
Jun 28 22:02:05 xps.local kernel: ACPI: PM: (supports S0 S4 S5)
Sadly, no S3 reported… and I couldn’t get it to report either. I’ve changed all reported (by other people who use XPS laptops) settings in the EFI settings that could possibly get S3 to report, to no avail…
I’m pretty sure my screen is turning off. I’ve also used systemctl suspend prior to closing the lid to ensure the system was actually in sleep.