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.
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)
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.
I cannot reproduce this error Which suspend mode are you using? You can check this using cat /sys/power/mem_sleep.
I’m using Arch with latest kernel 5.16.14-arch1-1 and “deep” suspend mode. No problems after suspending multiple times here. If you continue to hit this error, you may want to open a bug report at your Linux distribution for this. Maybe there is something going wrong at kernel level which can be fixed. And since @technical27 already found a workaround and the code snippet, chances are good to get this fixed.
I can confirm installing PipeWire to replace PulseAudio dropped my idle power around a watt! Definitely worth doing. I am running Ubuntu 20.04 with Kernel 5.14.9. I followed this guide:
If you are on 21.04, this might be a better choice (no need for the PPA):
Great summary! It may be good to add the warning that after resuming from suspend to s2idle, power consumption is way higher because only power states down to C3 are used (see Issues with power usage - #5 by Brad_J). This would seem a straight-up bug (not sure it is the kernel or bios). After a deep suspend, things are back to normal. But resuming from deep suspend takes rather long (also a bug?).
Maybe useful for others, my measurements with powertop (i7, 32GB, 3.07 bios; Debian/KDE,X11,pipewire, konsole only, radios off (flight mode), removed HDMI extension card
screen at 5%: 2.0 W, CPU 95% in C10
screen at 50%: 3.1 W
screen at 100%: 4.3 W
screen at 5%, insert HMDI: 2.9 W
after autosuspend HDMI: 2.4 W
screen at 5%, HDMI removed, radios on: 2.2 W (connected or not makes little difference)
Overall, idle power of ~2W (presumably, window manager turns screen off; ~2.4W at 100%) seems very reasonable! But concrete things/bug fixes that would make it generally happen are:
Just reproduced this and I was a bit baffled. I haven’t previously come across a description of this bug and never noticed it myself. It adds ~2.5W of idle power burn on mine. Has anyone done research on whether this is a hardware/firmware or kernel bug?
@lbkNhubert confirmed, it does resolve the problem. I’ll add that to the Ubuntu post-install formula even though most people using it probably have deep sleep as that’s the default. I actually use s2idle with suspend-then-hibernate so I’m affected. Thanks for the sleuth work @technical27 !
Edit: Aaand done. Whoever’s using this will automagically get the workaround applied.
I noticed a rather high power drain by the USB-A extension card.
My system: i7-1165G7, 64GB RAM 3200Mhz, Samsung 980 PRO 1TB. ArchLinux (kernel 5.17.3).
My settings: TLP default settings, no extension cards plugged, radios off, backlight 1%
With this I get ~2W idle power usage (according to powertop). However, as soon as I plug in a USB-A extension card, the power consumption increases by ~300-400mw for each USB-A card (tried with two cards). USB-C extension cards did not affect the power consumption.
@robert_b - I thought USB A was better than HDMI, but I just checked and confirmed that the USB A dongle takes about 300 mW. Without my HDMI and USBA, with radios off and 5% display, I got about 1.7 W idle (after waiting quite a while).
BIOS 3.08 is supposedly going to address battery drain during shutdown and possibly hibernate and standby. I wonder if they can address the drain of keeping usb-a’s ready to accept a device using the same methods.
Good news about framework is you have the option of the removing the cards you don’t need to eke out a bit more autonomy, unlike other laptops…
Does the power draw scale linearly with number of Type-A adapters? I don’t remember if I tried that experiment and I have been operating off the assumption that the power draw is from the controllers.
Native Type-A ports are usually connected to the PCH XHCI and won’t have these power draw issues which are TCSS related.
If I’m interpreting my results correctly, it scales linearly with the number of sides of the machine the USB-A’s are in. I get the same change to current_now with one or two USB-As on the same side, but double the change if I put one on each side.
There’s a lot of noise in the data, though, so don’t take my theory as gospel…
Just ran my first serious test of all my Framework/Manjaro battery tuning: getting work done while flying from Boston to Belize–one stopover, a total of 8 hours flight time.
Conditions:
Laptop started at its 90% charge limit.
No expansion card installed except one USB-C.
Wi-fi and bluetooth turned off.
Powertop runs auto-tune automatically; Gnome power control set to “Power Saver”.
Display most of the way down (which is fine in an airline cabin)
The system showed about 4.7-5W consumption most of the time.
I was basically reviewing a 200 page PDF document, so I wasn’t working the system very hard. I hibernated the system between flights.
After 4 hours of work time (1.5 hrs first flight, 2.5 hrs second flight), the laptop showed 68% charge.
Granted, I would expect a much shorter life if I was working the system harder and running wi-fi, but for offline work in ideal conditions, it looks like 8-10 hours is attainable. Surprised me a bit.
UPDATE
After a major network munge, I reinstalled and updated my Manjaro/GNOME installation. With minimal manual tuning other than “powertop --autotune” (no longer using TLP), I’m now seeing even better battery life. With the power manager set to Power Saver and the backlight at minimal, I’m running 3.5-4.5W on Firefox with 2 tabs, cloud services, and two separate mail clients. Balanced shows 4.5-5.5W. Kernel is 5.15.32-1.
Definitely shouldn’t have trouble making it through my flight to the Grenada Chocolate Festival next week ;- )
I’ve loved watching the information grow in these and other threads to the point where we can get the Framework to sip battery at idle. One thing I’ve been wondering for some time is how we can take advantage of Intel’s configurable TDP to limit battery usage under load. I found this thread that walked us through systemd units for setting limits on wattage through the powercap infrastructure.
Has anyone else played with this to see how it might affect battery usage/performance under load? I’m still saving up for my personal Framework laptop; since I’d like to keep my marriage in tact, I can’t really put my wife’s Framework through the ringer until maybe this weekend.