Just got hibernate and suspend-then-hibernate working on Ubuntu 21.10 following this guide, and I wanted to share in case anyone else runs into the same issues. I had to add resume and resume_offset to my grub and initramfs configs. However, mem_sleep_default caused a lot of problems for me, presumably because it was already enabled. Hibernate would work just fine, but when I ran suspend or suspend-then-hibernate, my WM (i3) would reload and appear fine for a few minutes, but then crashed. It seemed that the OS wasn’t aware of what was in $PATH, but I couldn’t find anything useful in my systemd logs that would indicate what the problem was. Removing mem_sleep_default from my grub config solved the issue.
2 Likes
Works for me, I’m on void, kernel 5.16.11, brave-browser (chromium’s derivative).
I have
--ignore-gpu-blocklist
--enable-gpu-rasterization
--enable-zero-copy
--enable-features=VaapiVideoDecoder
--use-gl=desktop
--disable-features=UseOzonePlatform
flags on ~/.config/brave-flags.conf.
And have enabled these options under chrome://flags
2 Likes
Weird, I have exactly the same setup with you and it was working before, but now it’s not.
What error do you get if you start your browser from the cli (in the stdout)?
Maybe it’s better to share this on this thread too that is a main thread of battery life tuning.
2 Likes
Does changing the battery life setting in the BIOS make a stark difference? Would it be worth mentioning here?
Just got my Framework Laptop (Bios 3.0.7, 64GB RAM, i5, WD Black SSD, Arch Linux with Gnome and pipewire) and want to report back after reading a lot here.
Hardware is just running fine out of the box and I got C9 power saving right away, but never reached C10. PSR is enabled by default (kernel 5.16.12-arch1-1), no problems at all with that.
Suspending using “mem_sleep_default=deep” works fine and uses 2% battery per hour, but waking up takes a few seconds longer than at my other laptops. Hibernation to disk is only slightly slower at waking up and works fine, too.
Using only tlp daemon with a few basic settings, 50% display brightness, keyboard lights, WiFi+BT enabled and 1x USB-C, 2x USB-A and card reader I got ~8W idle battery usage (peaks at ~9W) and ~7 hours runtime according to powertop.
I will try a few more tweaks in the next weeks, but so far I’m pretty happy with it for now. Got a tiny 65W USB-C charger from Anker which should do the job at most of the places where I will go to 
// Update
After removing all four extension cards I’m reaching C10 now, which results in ~6.1 W total according to powertop (just a few background application with nearly no load running). The card reader was listed as an extra USB device at powertop using a lot of energy (seems not be to realistic), this seems to interfere with C10. As long as it is attached, I cannot reach C10 (no SD-card inserted). When I remove this module, C10 will be used immediately and the power consumption drops for about 1.5-2W. The USB-A und USB-C modules seem to be working with C10.
7 Likes
Typing this on my Framework running Manjaro. Firefox with 11 tabs, including a few that autoupdate. No expansion cards except USB-C.
Powertop shows 4.6W with 35% C10 and 20% C8. Highest power use is coming from the CPU, iwlwifi, and the backlight.
1 Like
I found that disabling intel_pstate in exchange for acpi_cpufreq is a pretty big win as it allows the cpu’s min freq to drop down to as low as 400mhz. This increased my battery life by about 30%.
also @Peter_Conrad i had a similar issue with suspending/hibernating that i fixed by changing HibernateMode=platform shutdown to HibernateMode=shutdown instead.
3 Likes
@snek, thanks! I’ll try both of those. I just looked at my /etc/systemd/sleep.conf and everything under [sleep] appears to be commented out, which is interesting.
I’m fascinated powertop works for all you Archies out there.
I can’t, for the life of me, get powertop on Arch+Gnome41 to work properly. All I get is modprobe cpufreq_stats failedLoaded 750 prior measurements. So far I’m living with 5:30h of active use of the laptop (Firefox with youtube + Thunderbird + Signal + Discord). With Gnome’s “Freon” extension telling me that I have a general usage between 14V and 17V (14V when almost discharged, 17V when fully charged or during charging).
1 Like
How would I be able to disable intel_pstate? Thanks!
Add intel_pstate=disable to GRUB_CMDLINE_LINUX_DEFAULT= at /etc/default/grub.
2 Likes
I tried to post an answer to @Philipp_D here yesterday, but always got a “403 Forbidden”. I’m not sure if this is due to the content, so here is a new try…
Please try to run powertop using “–debug”, maybe this can help us.
@theraser Ohhh it has such a flag? Neat! I was not aware!
The output of that statement is pretty much a very often repeating:
Best parameter is 111
Changing score from 33321.750 to 33321.750
Changing value from 0.000 to 0.100
Retry is 85
delta is 0.0090
Best parameter is 2
Changing score from 33321.750 to 33321.692
Changing value from 0.641 to 0.636
Retry is 84
delta is 0.0090
Best parameter is 24
Changing score from 33321.692 to 33321.508
Changing value from 0.610 to 0.615
Retry is 82
The “Retry is” line counts down to 0 eventually and then starts over until this is output is reached:
Best parameter is 78
Changing score from 33172.151 to 33172.151
Changing value from 0.100 to 0.100
Final score 44.23 (750 points)
Parameter state
Value Name
0.46 alsa-codec-power (2)
2.82 backlight (3)
0.00 backlight-boost-100 (4)
0.00 backlight-boost-40 (5)
0.00 backlight-boost-80 (6)
4.51 backlight-power (7)
9.92 base power (8)
0.00 br-b74753b7788e-link-100 (9)
0.00 br-b74753b7788e-link-1000 (10)
0.00 br-b74753b7788e-link-high (11)
0.00 br-b74753b7788e-packets (12)
0.00 br-b74753b7788e-powerunsave (13)
0.00 br-b74753b7788e-up (14)
1.80 cpu-consumption (15)
23.76 cpu-wakeups (16)
0.00 disk-operations (17)
0.00 disk-operations-hard (18)
0.00 docker0-link-100 (19)
0.00 docker0-link-1000 (20)
0.00 docker0-link-high (21)
0.00 docker0-packets (22)
0.00 docker0-powerunsave (23)
1.04 docker0-up (24)
0.00 gpu-operations (25)
0.00 radio:hci0 (26)
0.00 radio:phy0 (27)
0.00 runtime-0000:00:00.0 (28)
0.00 runtime-0000:00:02.0 (29)
0.00 runtime-0000:00:04.0 (30)
0.00 runtime-0000:00:06.0 (31)
0.00 runtime-0000:00:07.0 (32)
0.00 runtime-0000:00:07.1 (33)
0.00 runtime-0000:00:07.2 (34)
0.00 runtime-0000:00:07.3 (35)
0.00 runtime-0000:00:08.0 (36)
0.00 runtime-0000:00:0a.0 (37)
0.00 runtime-0000:00:0d.0 (38)
0.00 runtime-0000:00:0d.2 (39)
0.00 runtime-0000:00:0d.3 (40)
0.00 runtime-0000:00:12.0 (41)
0.00 runtime-0000:00:14.0 (42)
0.00 runtime-0000:00:14.2 (43)
0.00 runtime-0000:00:15.0 (44)
0.00 runtime-0000:00:15.1 (45)
0.00 runtime-0000:00:15.3 (46)
0.00 runtime-0000:00:16.0 (47)
0.00 runtime-0000:00:1d.0 (48)
0.00 runtime-0000:00:1f.0 (49)
0.00 runtime-0000:00:1f.3 (50)
0.00 runtime-0000:00:1f.4 (51)
0.00 runtime-0000:00:1f.5 (52)
0.00 runtime-0000:01:00.0 (53)
0.00 runtime-0000:aa:00.0 (54)
0.00 runtime-17-0036 (55)
0.00 runtime-17-0037 (56)
0.00 runtime-17-0050 (57)
0.00 runtime-ACPI0003:00 (58)
0.00 runtime-ACPI000C:00 (59)
0.00 runtime-HID-SENSOR-200001.2.auto (60)
0.00 runtime-HID-SENSOR-200041.4.auto (61)
0.00 runtime-HID-SENSOR-2000e1.3.auto (62)
0.00 runtime-INT33A1:00 (63)
0.00 runtime-INT34C5:00 (64)
0.00 runtime-INTC1040:00 (65)
0.00 runtime-INTC1043:00 (66)
0.00 runtime-INTC1043:01 (67)
0.00 runtime-NTC0702:00 (68)
0.00 runtime-PNP0C09:00 (69)
0.00 runtime-PNP0C0A:00 (70)
0.00 runtime-PNP0C0C:00 (71)
0.00 runtime-PNP0C0D:00 (72)
0.00 runtime-PNP0C14:00 (73)
0.00 runtime-PNP0C14:01 (74)
0.00 runtime-USBC000:00 (75)
0.00 runtime-alarmtimer.0.auto (76)
0.00 runtime-coretemp.0 (77)
0.00 runtime-efi-framebuffer.0 (78)
0.00 runtime-efivars.0 (79)
0.00 runtime-i2c-0 (80)
0.00 runtime-i2c-1 (81)
0.00 runtime-i2c-10 (82)
0.00 runtime-i2c-11 (83)
0.00 runtime-i2c-12 (84)
0.00 runtime-i2c-13 (85)
0.00 runtime-i2c-14 (86)
0.00 runtime-i2c-15 (87)
0.00 runtime-i2c-16 (88)
0.00 runtime-i2c-17 (89)
0.00 runtime-i2c-2 (90)
0.00 runtime-i2c-3 (91)
0.00 runtime-i2c-4 (92)
0.00 runtime-i2c-5 (93)
0.00 runtime-i2c-6 (94)
0.00 runtime-i2c-7 (95)
0.00 runtime-i2c-8 (96)
0.00 runtime-i2c-9 (97)
0.00 runtime-i2c-FRMW0001:00 (98)
0.00 runtime-i2c-PIXA3854:00 (99)
0.00 runtime-i2c-SONY488A:00 (100)
0.00 runtime-i2c_designware.0 (101)
0.00 runtime-i2c_designware.1 (102)
0.00 runtime-i2c_designware.2 (103)
0.00 runtime-i8042 (104)
0.00 runtime-iTCO_wdt (105)
0.00 runtime-idma64.0 (106)
0.00 runtime-idma64.1 (107)
0.00 runtime-idma64.2 (108)
0.00 runtime-intel_rapl_msr.0 (109)
0.00 runtime-microcode (110)
0.00 runtime-pcspkr (111)
0.00 runtime-pmt_telemetry.1.auto (112)
0.00 runtime-reg-dummy (113)
0.00 runtime-regulatory.0 (114)
0.00 runtime-rtc-efi.0 (115)
0.00 runtime-rtc_cmos (116)
0.00 runtime-serial8250 (117)
0.00 runtime-snd-soc-dummy (118)
0.00 usb-device-1d6b-0002 (119)
0.00 usb-device-1d6b-0003 (120)
0.00 usb-device-27c6-609c (121)
1.22 usb-device-32ac-0002 (122)
0.00 usb-device-8087-0032 (123)
0.00 wlan0-link-100 (124)
0.00 wlan0-link-1000 (125)
0.00 wlan0-link-high (126)
0.00 wlan0-packets (127)
0.00 wlan0-powerunsave (128)
0.00 wlan0-up (129)
0.00 xwakes (130)
Score: 2.6 (33172.2)
Guess: 9.9
Actual: 6.5
This looks pretty good, powertop seems to be working without problems
Using Arch myself powertop needs a few seconds to start, what happens if you run it without --debug and wait? If it just hangs forever, maybe reinstalling helps. But this topic may be better discussed at the Arch Linux Forum as this likely is a software error and has nothing to do with the Framework Laptop.
I was having trouble hitting PC10, but then I found out it works after a reboot/fresh boot but not after suspending. It always works during suspend, but after the first suspend, it no longer worked in normal use until the next power cycle.
I spent some time investigating and turns out this code is responsible for that
The fix, add nvme.noacpi=1 to your kernel parameters.
PC10 now works after suspending and power usage while under light use should improve.
17 Likes
Excellent catch! I knew that I had hit C10 once or twice in the past, but couldn’t seem to replicate those results reliably. This explains it.
For those who need it spelled out more: I verified the fix by following these steps:
- Reboot
- Verify hitting C10 with
powertop - Suspend, then re-awaken
- Verify not hitting C10
I then added nvme.noacpi=1 to GRUB_CMDLINE_LINUX_DEFAULT (see here for how to do that) and repeated the procedure above. After the change, step (4) shows that I’m getting to C10 even after a suspend.
I’m using
- Manjaro Linux
- Kernel 5.15.25-1-MANJARO
- TLP for power management (all default settings, for now)
1 Like
Well, almost.
It seems that running Firefox also seems to keep me from getting to C10. With powertop running and Firefox open, I never drop below C8, but I see an immediate drop to C10 when I quit Firefox. I do tend to have a fair number of tabs open, but nothing animated until I start watching YouTube or Netflix, etc. I do have Gmail and Google Calendar in pinned tabs, but nothing else that would be actively repainting themselves. (And they’re certainly not on the screen all the time.)
EDIT: Starting Firefox with a new profile still allows dropping to C10, so it’s clearly something I’m doing within Firefox that keeps me running hotter. 