PINE64
Power Consumption on Suspend - Printable Version

+- PINE64 (https://forum.pine64.org)
+-- Forum: PinePhone (https://forum.pine64.org/forumdisplay.php?fid=120)
+--- Forum: PinePhone Software (https://forum.pine64.org/forumdisplay.php?fid=121)
+---- Forum: Mobian on PinePhone (https://forum.pine64.org/forumdisplay.php?fid=139)
+---- Thread: Power Consumption on Suspend (/showthread.php?tid=18519)

Power Consumption on Suspend - JudgeFudge - 07-17-2023

Hello there, newbie here!

I have the Pinephone in the 3 GB Version with the Keyboard case, using it as a PDA with Gnome 3 (NOT phosh) as the DE, modem disabled via hardware switch.
Software works great, Performance as expected and battery time in combination with the battery case no problem in active use. However, in suspend, the battery consumption stays unreasonably high, draining battery of phone and case in around 24 hours, thats more than 1 Watt in suspend to RAM.

I've tried around a lot by now, but I've hit a wall here and wanted to ask if there are similar problems and workarounds.

First, the suspend is triggered via systemd, so the /etc/systemd/sleep.conf is used. I've set the SuspendState to mem, drain remains high. The drain is even higher when set to standby or freeze, although not much. Gnome 3 uses systemd for this, I've tested it by setting hibernate settings into the suspendvariables with the expected outcome.

So forward to the logs. Journalctl says
Code:
Jul 10 22:35:46 mobian systemd[1]: Reached target sleep.target - Sleep.
Jul 10 22:35:46 mobian systemd[1]: Starting systemd-suspend.service - System Suspend...
Jul 10 22:35:46 mobian systemd-sleep[7427]: Entering sleep state 'suspend'...
Jul 10 22:35:46 mobian kernel: PM: suspend entry (deep)
Jul 11 01:51:03 mobian kernel: Filesystems sync: 0.115 seconds
Jul 11 01:51:03 mobian kernel: Freezing user space processes
Jul 11 01:51:03 mobian kernel: Freezing user space processes completed (elapsed 0.012 seconds)
Jul 11 01:51:03 mobian kernel: OOM killer disabled.
Jul 11 01:51:03 mobian kernel: Freezing remaining freezable tasks
Jul 11 01:51:03 mobian kernel: Freezing remaining freezable tasks completed (elapsed 0.006 seconds)
Jul 11 01:51:03 mobian kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Jul 11 01:51:03 mobian kernel: musb-sunxi 1c19000.usb: sunxi-musb does not have ULPI bus control register
Jul 11 01:51:03 mobian kernel: Disabling non-boot CPUs ...
Jul 11 01:51:03 mobian kernel: psci: CPU1 killed (polled 4 ms)
Jul 11 01:51:03 mobian kernel: psci: CPU2 killed (polled 4 ms)
Jul 11 01:51:03 mobian kernel: psci: CPU3 killed (polled 4 ms)
Jul 11 01:51:03 mobian kernel: Enabling non-boot CPUs ...
Jul 11 01:51:03 mobian kernel: Detected VIPT I-cache on CPU1
Jul 11 01:51:03 mobian kernel: arch_timer: CPU1: Trapping CNTVCT access
Jul 11 01:51:03 mobian kernel: CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
Jul 11 01:51:03 mobian kernel: CPU1 is up
Jul 11 01:51:03 mobian kernel: Detected VIPT I-cache on CPU2
Jul 11 01:51:03 mobian kernel: arch_timer: CPU2: Trapping CNTVCT access
Jul 11 01:51:03 mobian kernel: CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
Jul 11 01:51:03 mobian kernel: CPU2 is up
Jul 11 01:51:03 mobian kernel: Detected VIPT I-cache on CPU3
Jul 11 01:51:03 mobian kernel: arch_timer: CPU3: Trapping CNTVCT access
Jul 11 01:51:03 mobian kernel: CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
Jul 11 01:51:03 mobian kernel: CPU3 is up
Jul 11 01:51:03 mobian kernel: sunxi-rsb 1f03400.rsb: RSB running at 4000000 Hz
Jul 11 01:51:03 mobian kernel: pinephone-keyboard 2-0015: Failed to read scan data: -13
Jul 11 01:51:03 mobian kernel: musb-sunxi 1c19000.usb: sunxi-musb does not have ULPI bus control register
Jul 11 01:51:03 mobian kernel: OOM killer enabled.
Jul 11 01:51:03 mobian kernel: Restarting tasks ... done.
Jul 11 01:51:03 mobian kernel: PM: suspend exit

As can be seen, the suspend entry is deep, so this is done to RAM in theory, this is no problem with falling back to s2idle or anything like that.
The interesting and thing here seems to be the fact that the 
Code:
Freezing user space processes
Is done at wakeup, not at sleep. I am relatively sure that this is the issue, as I've found unrelated issues several years old referring to this as the culprit for high suspend energy consumption on laptops of different kinds. 
https://askubuntu.com/questions/828486/kernel-suspends-too-quickly-upon-resume-continues-suspend-tasks
Some were fixed by bios settings, some by ACPI Settings, for what I've seen. Both don't show up in the wiki, so I am asking here for two things:


1. Is this a normal behavior others are experiencing? A suspend that high would drain a Pinephone in about 8 Hours, no usage and no active modem. 

2. Any Idea how to fix this? Is this due to a newer kernel? This is freshly setup, so I dont have a specific fallback right now.



Before settling for Gnome, I've played around with lomiri, but I've uninstalled it. Otherwise the image is pretty clean from a software standpoint (no system installations, just userspace programs like chromium or gedit). All Packages are up to date of course, no external repos were added.

Code:
mobian@mobian:~$ uname -a
Linux mobian 6.1-sunxi64 #1 SMP Mon Jul  3 04:42:56 UTC 2023 aarch64 GNU/Linux
mobian@mobian:~$ cat /etc/debian_version
12.0

If you need more debugging information, don't hesitate to ask. If you think this is the wrong place for those questions I apologize and would be glad to get a hint were I can find some help.

RE: Power Consumption on Suspend - JudgeFudge - 07-24-2023

I cannot replicate it anymore, after trying to find a solution. Currently, only two possibilities arise as the culprit:

1. apt upgrade updated beside some other stuff systemd and dbus. A new initramfs was generated as well. Unfortunately, I have not found useful changelogs for those updates... Full upgrade log:
Commandline: apt upgrade

Requested-By: mobian (1000)
Upgrade: libsynctex2:arm64 (2022.20220321.62855-5.1, 2022.20220321.62855-5.1+deb12u1), libcups2:arm64 (2.4.2-3, 2.4.2-3+deb12u1), libyajl2:arm64 (2.1.0-3, 2.1.0-3+deb12u2), udev:arm64 (252.6-1, 252.12-1~deb12u1), dbus-user-session:arm64 (1.14.6-1, 1.14.8-2~deb12u1), libnss-myhostname:arm64 (252.6-1, 252.12-1~deb12u1), libnftables1:arm64 (1.0.6-2, 1.0.6-2+deb12u1), cups-bsd:arm64 (2.4.2-3, 2.4.2-3+deb12u1), desktop-base:arm64 (12.0.6, 12.0.6+nmu1~deb12u1), cups-common:arm64 (2.4.2-3, 2.4.2-3+deb12u1), libldb2:arm64 (2:2.6.2+samba4.17.8+dfsg-2, 2:2.6.2+samba4.17.9+dfsg-0+deb12u3), libpam-systemd:arm64 (252.6-1, 252.12-1~deb12u1), libvte-2.91-gtk4-0:arm64 (0.70.3-1, 0.70.6-1~deb12u1), usb.ids:arm64 (2023.01.16-1, 2023.05.17-0+deb12u1), libkpathsea6:arm64 (2022.20220321.62855-5.1, 2022.20220321.62855-5.1+deb12u1), libmutter-11-0:arm64 (43.4-2, 43.6-1~deb12u1), cups-client:arm64 (2.4.2-3, 2.4.2-3+deb12u1), dbus-daemon:arm64 (1.14.6-1, 1.14.8-2~deb12u1), libjavascriptcoregtk-4.1-0:arm64 (2.40.3-2~deb12u1, 2.40.3-2~deb12u2), libsystemd0:arm64 (252.6-1, 252.12-1~deb12u1), gir1.2-javascriptcoregtk-4.1:arm64 (2.40.3-2~deb12u1, 2.40.3-2~deb12u2), libnss-systemd:arm64 (252.6-1, 252.12-1~deb12u1), locales-all:arm64 (2.36-9, 2.36-9+deb12u1), gir1.2-webkit2-4.1:arm64 (2.40.3-2~deb12u1, 2.40.3-2~deb12u2), libwbclient0:arm64 (2:4.17.8+dfsg-2, 2:4.17.9+dfsg-0+deb12u3), libdbus-1-3:arm64 (1.14.6-1, 1.14.8-2~deb12u1), dbus-bin:arm64 (1.14.6-1, 1.14.8-2~deb12u1), libjavascriptcoregtk-6.0-1:arm64 (2.40.3-2~deb12u1, 2.40.3-2~deb12u2), libsmbclient:arm64 (2:4.17.8+dfsg-2, 2:4.17.9+dfsg-0+deb12u3), libxml2:arm64 (2.9.14+dfsg-1.2, 2.9.14+dfsg-1.3~deb12u1), mutter-common:arm64 (43.4-2, 43.6-1~deb12u1), gnome-shell:arm64 (43.4-1, 43.6-1~deb12u1), systemd:arm64 (252.6-1, 252.12-1~deb12u1), libudev1:arm64 (252.6-1, 252.12-1~deb12u1), libc6:arm64 (2.36-9, 2.36-9+deb12u1), locales:arm64 (2.36-9, 2.36-9+deb12u1), libvte-2.91-common:arm64 (0.70.3-1, 0.70.6-1~deb12u1), gnome-maps:arm64 (43.4-1, 43.5-2~deb12u1), systemd-resolved:arm64 (252.6-1, 252.12-1~deb12u1), gir1.2-mutter-11:arm64 (43.4-2, 43.6-1~deb12u1), base-files:arm64 (12.4, 12.4+deb12u1), gnome-shell-common:arm64 (43.4-1, 43.6-1~deb12u1), dbus-session-bus-common:arm64 (1.14.6-1, 1.14.8-2~deb12u1), libwebkit2gtk-4.1-0:arm64 (2.40.3-2~deb12u1, 2.40.3-2~deb12u2), libc-l10n:arm64 (2.36-9, 2.36-9+deb12u1), samba-libs:arm64 (2:4.17.8+dfsg-2, 2:4.17.9+dfsg-0+deb12u3), sudo:arm64 (1.9.13p3-1, 1.9.13p3-1+deb12u1), libc-bin:arm64 (2.36-9, 2.36-9+deb12u1), libsystemd-shared:arm64 (252.6-1, 252.12-1~deb12u1), systemd-sysv:arm64 (252.6-1, 252.12-1~deb12u1), libwebkitgtk-6.0-4:arm64 (2.40.3-2~deb12u1, 2.40.3-2~deb12u2), gnome-shell-extension-prefs:arm64 (43.4-1, 43.6-1~deb12u1), libvte-2.91-0:arm64 (0.70.3-1, 0.70.6-1~deb12u1), dbus-system-bus-common:arm64 (1.14.6-1, 1.14.8-2~deb12u1), dbus:arm64 (1.14.6-1, 1.14.8-2~deb12u1)


2. I disabled the zram0 and use a regular swapfile because I tried to work with hibernate as an alternative. The two systemwide relevant changes here were:

echo 'vm.swappiness=1' | sudo tee /etc/sysctl.d/swapiness
sudo systemctl disable swap-create@zram0

I cannot reactivate the zram the same way, so I have not verified this.
Some other changes to kernel arguments are explicitly meant for hibernation and are definitly not responsible.


However, this is not everything I tried, so for the record:
It is not due to the keyboard being connected or loading the battery.
It is not due to the lockscreen, gsettings set org.gnome.desktop.lockdown disable-lock-screen 'true' has no effect.

Still would be glad to get SOME feedback on similar behavior. However, for my scenario, this seems fixed right now, standby time with full battery should now be between 4 and 10 days from very rough extrapolation, meaning 300 and 120mWh, sounds more realistic to me.

RE: Power Consumption on Suspend - jakfish - 07-25-2023

You've certainly tested up and down, and the only thing to add from my own experience is to turn off the keyboard (two quick clicks of its side button or one long press of more than 10 seconds).

The reason I suggest this is because if I shut down my PP Beta/kb and don't turn off the kb, I get a big power drain by the next day.

If that doesn't help, you could try (if you haven't already) Megi's custom kb firmware: https://xnux.eu/log/078.html to help matters along.

RE: Power Consumption on Suspend - JudgeFudge - 07-26-2023

Thanks for the feedback!
I have tested this part thoroughly as well, and while there would be certainly a difference in turning the keyboard off, I could not measure one relevant enough (no power meter, simply battery consumption/X hours).
However, if this is a problem for you, I stumbled upon a solution you may find handy. You can turn the battery charging of the keyboard off programmatically, and turn it on again. Also, you can run scripts triggered right before and after suspend. This means that you would not have to do it manually.
For this to work, you will first need to compile the pinephone keyboard software:

sudo apt install -y php gcc make git i2c-tools
sudo systemctl disable apache2 && sudo systemctl stop apache2
git clone https://megous.com/git/pinephone-keyboard
cd pinephone-keyboard
make
sudo modprobe i2c-dev
echo i2c-dev | sudo tee -a /etc/modules
sudo cp build/ppkb-charger-ctl /usr/local/bin/
sudo /usr/local/bin/ppkb-charger-ctl info

After that, you can write a script that triggers this ppkb-charger-ctl power-off or similar (as root user, try around the commands)
by placing a bashscript in /usr/lib/systemd/system-sleep/ with something like

#!/bin/sh
if [ "${1}" == "pre" ]; then
# Do the thing you want before suspend here, e.g.:
/usr/local/bin/ppkb-charger-ctl power-off
elif [ "${1}" == "post" ]; then
# Do the thing you want after resume here, e.g.:
/usr/local/bin/ppkb-charger-ctl power-on
fi

The sleep/resume script is entirely untested, but I managed to control the keyboard with the commands from ppkb-charger-ctl.

Maybe that helps, you can ask if that interests you and you need more info Smile

RE: Power Consumption on Suspend - jakfish - 07-26-2023

Wow, that's impressive work. My distro-hopping has landed me on Manjaro Phosh with an xfce desktop (I don't use the PP for anything except a computer and keystroke as much as possible given the unfriendly touch of xfce).

So at this point, I don't even suspend, since that drops me back into shell/x-restart, I just screen-blank and wifi-toggle. Even without suspend, I have a ton of daily juice, but should I move to another distro, I will try your scripting.

I do have a wifi toggle script, should you be interested.

RE: Power Consumption on Suspend - JudgeFudge - 07-27-2023

That would be interesting, as this was the reason i abandoned my hibernation efforts. I got them working after some weird stuff (that include the ZRAM), but the wifi was broken beyond repair until restart, and a disabled NetworkManager broke the hibernation for some reason...

I also started with Xfce, but Gnome 3 turned out to be far superior for touch, without being a resource drain like some people assume - it has autorotate, separates the desktop itself from the application menu (which means more space for actual app usage) and you can mark text pretty intuitively. Long tap right click is also supported in the settings, and nautilus has a single tap folder open option... This is the closest I've ever seen to a convergence DE

RE: Power Consumption on Suspend - jakfish - 07-28-2023

Wifi toggle:

Code:
#!/bin/bash
if [ "$(nmcli radio wifi)" == "enabled" ]
then
    notify-send -i /usr/share/icons/hicolor/scalable/actions/close-symbolic.svg "WIRELESS DISABLED" -t 2
    nmcli radio wifi off
else
    notify-send -i /usr/share/icons/HighContrast/scalable/status-extra/nm-signal-100.svg "WIRELESS ENABLED" -t 2
    nmcli radio wifi on
fi
exit 0

With Manjaro Phosh at least, notify-send has issues (gxmessage works better), but notify-send is just window dressing in this case, and xfce has its own notifications.

I run xfce on everything so I've learned to live with keystroking rather than touch-screening. I'm always amazed that it works so well. Just got box86 running so Word 97 and my favorite database program (HanDBase) are available, and I even use x-86 npopUK for my email since I can't stand geary and tbird is so slow. The x-86 programs can take a while to load, but once minimized, they consume very little cpu.

Good to know about Gnome3 success.

RE: Power Consumption on Suspend - Kevin Kofler - 07-28-2023

(07-27-2023, 08:48 AM)JudgeFudge Wrote: I also started with Xfce, but Gnome 3 turned out to be far superior for touch, without being a resource drain like some people assume - it has autorotate, separates the desktop itself from the application menu (which means more space for actual app usage) and you can mark text pretty intuitively. Long tap right click is also supported in the settings, and nautilus has a single tap folder open option... This is the closest I've ever seen to a convergence DE
That would be because not only has gnome-shell been using some design concepts from mobile DEs from the beginning, even on desktops (e.g., running all applications maximized without window decorations), but there has also been work recently to allow using the standard gnome-shell instead of Phosh on mobile devices. (There are already some OS images for the PinePhone that allow you to try that out.)

RE: Power Consumption on Suspend - JudgeFudge - 07-29-2023

Interesting, that explains what I found out by experimentation! They are definitely on a good way there, at least for this usage scenario (as design is always a bit more tricky in regard to universal applicability).

Thanks for the script, I will maybe play around again with hibernation and see if this fixes the issue!

Thanks for the input and help, I will mark the thread as resolved for now, as this gets more and more off-topic Big Grin