I’m on a Ryzen 7 Framework with OpenSUSE and sometimes my Framework loses substantial battery over night. upower just skips that time, but journalctl has some output:
Nov 04 03:41:52 SusFrame systemd[1]: Reached target Sleep.
Nov 04 03:41:52 SusFrame systemd[1]: Starting System Suspend...
Nov 04 03:41:52 SusFrame rtkit-daemon[2466]: Successfully made thread 2833 of process 2798 owned by 'LukDeHuk' high priority at nice level 0.
Nov 04 03:41:52 SusFrame rtkit-daemon[2466]: Successfully made thread 2833 of process 2798 owned by 'LukDeHuk' RT at priority 20.
Nov 04 03:41:52 SusFrame systemd-sleep[1639]: INFO: Skip running /usr/lib/systemd/system-sleep/grub2.sleep for suspend
Nov 04 03:41:52 SusFrame systemd-sleep[1633]: Entering sleep state 'suspend'...
Nov 04 03:41:52 SusFrame kernel: PM: suspend entry (s2idle)
Nov 04 03:41:52 SusFrame kernel: Filesystems sync: 0.023 seconds
Nov 04 12:03:24 SusFrame kernel: Freezing user space processes
Nov 04 12:03:24 SusFrame kernel: Freezing user space processes completed (elapsed 0.002 seconds)
Nov 04 12:03:24 SusFrame kernel: OOM killer disabled.
Nov 04 12:03:24 SusFrame kernel: Freezing remaining freezable tasks
Nov 04 12:03:24 SusFrame kernel: Freezing remaining freezable tasks completed (elapsed 0.092 seconds)
Nov 04 12:03:24 SusFrame kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Nov 04 12:03:24 SusFrame kernel: queueing ieee80211 work while going to suspend
Nov 04 12:03:24 SusFrame kernel: ACPI: EC: interrupt blocked
Nov 04 12:03:24 SusFrame kernel: amd_pmc AMDI0009:00: Last suspend didn't reach deepest state
Nov 04 12:03:24 SusFrame kernel: ACPI: EC: interrupt unblocked
Nov 04 12:03:24 SusFrame kernel: [drm] PCIE GART of 512M enabled (table at 0x000000801FD00000).
Nov 04 12:03:24 SusFrame kernel: amdgpu 0000:c1:00.0: amdgpu: SMU is resuming...
Nov 04 12:03:24 SusFrame kernel: amdgpu 0000:c1:00.0: amdgpu: SMU is resumed successfully!
Nov 04 12:03:24 SusFrame kernel: nvme nvme0: Shutdown timeout set to 8 seconds
Nov 04 12:03:24 SusFrame kernel: nvme nvme0: 12/0/0 default/read/poll queues
Nov 04 12:03:24 SusFrame kernel: [drm] VCN decode and encode initialized successfully(under DPG Mode).
Nov 04 12:03:24 SusFrame kernel: amdgpu 0000:c1:00.0: [drm:jpeg_v4_0_hw_init [amdgpu]] JPEG decode initialized successfully.
Nov 04 12:03:24 SusFrame kernel: amdgpu 0000:c1:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
Nov 04 12:03:24 SusFrame kernel: amdgpu 0000:c1:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
Nov 04 12:03:24 SusFrame kernel: amdgpu 0000:c1:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
Ran the fixes and added rtc_cmos.use_acpi_alarm=1 to my kernel parameters. The script now shows no errors, let’s see if the battery is (almost) full tomorrow morning
UPDATE: lost about 10% over 6h instead of 50-60%, so definitely an improvement. Not perfect though, I’ll probably have to investigate further as that still sounds like quite a bit.
Lost about 10% overnight on sleep with Ubuntu 23.10 as well (I have not run the fix linked by Mario). Was hoping to avoid using hibernate on the AMD board like I had to with the 11th gen intel board…
I suggest tonight when you are ready to go to sleep, trigger the suspend using that script and however long you want to sleep for. Then when you wake up take a look at the report from the script and see what the power draw measured by the script is and compare that against what Framework suggests it should be.
The script will also capture debugging data that might be helpful in identifying any other related programs over the sleep cycle.
If the draw ends up being in line with Framework’s numbers and it’s still too much for you another thing you can look into using is SuspendThenHibernate which is a systemd feature that lets you suspend the machine for a period of time and if it’s suspended longer than that it wakes it up and hibernates it. Set it for like an hour or two to swich from suspend to hibernate so you can get quick wakeup between meetings or classes or what not and lower battery usage over night.
When my computer is in the same state as when I left it last, it reduces my cost of context switching, even if it is from the night before. This is a better user experience.
If Linux had better support for restoring state from a cold boot (window position, open applications, etc) then I would consider turning it off overnight.
For some reason, I couldn’t get hibernate working on OpenSUSE Tumbleweed Gnome, but it works after reinstalling with KDE and without disk encryption. Using that now.
My average battery life so far is in the neighborhood of about 7-9h, but I have IntelliJ open almost all the time. Signal a lot too.
Will see how good suspend-then-hibernate works tonight.
Search results show that it there are lots of caveats to getting hibernate working properly on Linux in general and it’s not part of the default installation of Fedora 39.
If you have a guide to configuring hibernate on Fedora 39 specific to the AMD Framework it would be much appreciated if you could share it.
Add the resume module in the initial RAM file system (initramfs); the temporary environment the bootloader runs in by creating a new configuration file at /etc/dracut.conf.d/resume.conf and adding the following option:
add_dracutmodules+=" resume "
The whitespace in the above code snippet is significant. Make sure you set the option exactly as shown.
Execute sudo dracut -f command to generate your new initramfs.
Identify your swap partition’s UUID by executing the command sudo blkid | grep swap (ignore any “zram” labels)
Run sudo vi /etc/default/grub and append the following to the end of your GRUB_CMDLINE_LINUX option. Replace your-swap-identifier with the UUID for the swap partition you identified above. ([…] is a placeholder for the existing values in your configuration.)
Regenerate your grub config by running sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Run sudo vi /etc/systemd/sleep.conf and make sure it includes the following exactly. You may need to uncomment or add them if they’re not present in your configuration:
There aren’t that many, you basically just need to tell the boot-loader where the swap file/partition is (even with encryption and stuff that’s pretty much it) but it not being part of default installations is indeed a bit of an issue.
And of course you’ll need enough swap to actually hibernate and you probably should not use hibernate unencrypted cause well that’d put the whole content of your ram on an unencrypted disk XD.
That’s another neat part about it, it barely needs hardware support so there isn’t really any framework speciffic stuff here. Hibernate is save state to disk → shut down, somewhat normal early boot/hw initialisation → load save state which is all the os. There is a lot less of telling the hardware to do something special and hope it does it.
Hello did you succeed it with or without secure boot ?
As far as I’ve red,it’s now pretty difficult to enter hibernation with last kernels, due to kernel lockdown in secure boot.
Seem to need kernel patch and rebuilding or desactivate secure boot…
