Power Consumption on Suspend
07-24-2023, 08:28 AM
(This post was last modified: 07-24-2023, 08:29 AM by JudgeFudge.
Edit Reason: Syntax
)
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.
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.