Re: [DNG] Beowulf to Chimaera update breaks suspend on laptop
On 7/4/22 20:58, Brad Campbell via Dng wrote:
> G'day,
>
> I could use a bit of advice if anyone has the relevant experience.
>
> My laptop is running Devuan Beowulf currently, but this suspend config goes
> back at least 10 years.
> It suspends / hibernates using pm-utils with the uswsusp back-end onto a
> dmycrypted swap partition. The kernel is vanilla with a cut-down config and
> locally compiled.
>
> This works flawlessly and has done since I set it up. The GUI is xfce4 and
> when I hit the power button xfce4-power-manager does all the right things
> (which is hit up pm-utils and get out of its way).
>
> Last night I upgraded to Chimaera. This installed elogind and tries to use
> that to pull the relevant kernel levers to suspend. Unfortunately on my
> system, while it suspends most times, it comes back about 1 in 10 and then
> usually the nvme is broken and it dies in a ball of flames. I spent the best
> part of a day experimenting with the in-kernel suspend mechanisms and I can't
> seem to make it work, while the trusty old uswsusp userspace suspend/resume
> works first time every time.
>
> So, I'm asking for either :
> - Experience in making the in-kernel mechanisms work; or preferably
> - How to remove elogind from an xfce4 Chimaera install and make
> xfce4-power-manager use pm-utils like it used to.
>
> Does anyone have any ideas?
>
Just to follow this up, it appears to be related to power management. When
unplugged pm-utils pulls a pile of levers in the kernel to reduce power
consumption. This does reduce on-battery consumption significantly, but it also
breaks resume on a number of pcie devices. In the past I had issues with both
brcmfmac and the xhci driver, so I was unloading those pre-suspend and
re-loading on resume. I also had to serialize the device suspend as async
seemed to lock up.
By inserting some magic into the suspend hook to undo all the power management
magic, it would appear I no longer need to unload any modules and suspend,
hibernate and hybrid suspend all work and resume as-was.
I don't want to speak too soon, but so far I have 24 hybrid cycles on the
machine and it's still resuming ok.
To be specific, pre-suspend I'm using :
echo 0 > /sys/power/pm_async
echo default > /sys/module/pcie_aspm/parameters/policy
/usr/lib/pm-utils/power.d/pci_devices false
Async device freeze off and then undo all the power saving modes.
Once I'm convinced it's reliable, I'll start peeling these commands back one by
one to see which one(s) cause the issues, but at the moment it's looking happy.
Now, why this all works on Beowulf and doesn't on Chimaera is entirely a
mystery give the pm-utils, uswsusp and kernel config is identical is beyond me,
but I figure as both pm-utils and uswsusp are effectively dead I'm going to
have to use the in-kernel stuff at some point.
My current hook script in /lib/elogind/system-sleep/Hooks.sh :
#!/bin/bash
do_wakeup () {
for i in LID0 XHC1 ; do
if [ -z "`cat /proc/acpi/wakeup | grep $i | grep disabled`" ] ;
then
echo $i > /proc/acpi/wakeup
fi;
done;
}
do_suspend() {
echo N > /sys/module/printk/parameters/console_suspend
echo 0 > /sys/power/image_size
echo 0 > /sys/power/pm_async
echo default > /sys/module/pcie_aspm/parameters/policy
/usr/lib/pm-utils/power.d/pci_devices false
do_wakeup
/etc/init.d/openvpn stop
xscreensaver-command -lock
sync
}
do_resume() {
for i in gpe66 gpe4E ; do
echo disable > /sys/firmware/acpi/interrupts/$i 2>/dev/null
done;
do_wakeup
rfkill block bluetooth
echo 120 > /sys/class/leds/smc::kbd_backlight/brightness
xscreensaver-command -deactivate
if [ "`cat /sys/class/power_supply/ADP1/online`" -eq 1 ] ; then
pm-powersave false
else
pm-powersave true
fi
}
PID=`pgrep xfce4-session`
USER=`ps -p $PID -o ruser=`
export DISPLAY=:0.0
export XAUTHORITY=/home/$USER/.Xauthority
case $1/$2 in
pre/*)
do_suspend
;;
post/*)
do_resume
;;
esac
Regards,
Brad
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] devuan chimaera and NUT shutdown failure
Hello folks - hope your day is going well. I had a funky power situation this morning, power problems at home are super rare and this is the first time I want to say in 10+ years that I've actually had my UPS run out of battery on me. What surprised me was that the shutdown command coming from NUT to my devuan chimaera server failed to run. So the system shutdown unclean. I never tested it I just assumed it would work but in the worst case if it did not(as it did not) not a huge deal for me. The error in the log was upsmon[2384]: parent: Unable to call shutdown command: /sbin/shutdown -h +0 But I looked into it a bit further and it appears to be an issue with Devuan itself, fortunately the fix(for NUT) is simple, am unsure how else to report this. I poked at Devuan's bug reporting site and it says the package nut-client does not exist(it lists several other NUT packages though), so perhaps Devuan does no modifications to the Debian upstream package. The command NUT uses to shutdown by default is this: SHUTDOWNCMD "/sbin/shutdown -h +0" This does not work on Devuan Chimera. It does work on Ubuntu 20.04, and on Devuan beowulf. I don't have a Debian system handy that I'm willing to shut down to test, but am assuming it probably works on Debian as well. I did download the NUT source package from Debian stable(along with the other files and used dpkg-source to extract) https://packages.debian.org/bullseye/nut-client And did my best to verify that command is what ships with Debian(that is what is in the original source and I found no evidence there was a Debian patch to change the behavior). On Devuan Chimaera running this command results in just getting the usage statement back: -- root@repos:~# /sbin/shutdown -h +0 Usage:shutdown [-akrhPHfFnc] [-t sec] time [warning message] -a: use /etc/shutdown.allow -k: don't really shutdown, only warn. -r: reboot after shutdown. -h: halt after shutdown. -P: halt action is to turn off power. can only be used along with -h flag. -H: halt action is to just halt. can only be used along with -h flag. -f: do a 'fast' reboot (skip fsck). -F: Force fsck on reboot. -n: do not go through "init" but go down real fast. -c: cancel a running shutdown. -q: quiet mode - display fewer shutdown warnings. -Q: full quiet mode - display only final shutdown warning. -t secs: delay between warning and kill signal. ** the "time" argument is mandatory! (try "now") ** - So the workaround I guess would be to change the +0 to say now in the NUT configuration. My Beowulf system has sysvinit (which shutdown appears to come from) version 2.93-8+devuan1 and my Chimeara system has 2.96-7+devuan1. Nothing stands out in the changelog for sysvinit to explain this kind of behavioral change. Or perhaps the bug is in the sysvinit package and that the fact that this shutdown command does not work is the problem rather than changing NUT to call another option. I don't know. Personally when I shut down a system I always use the halt command and to reboot I always use reboot, I never use shutdown just out of habbit(Linux user since 1996). So I don't have an opinion one way or another to judge what the most correct behavior is. thanks nate ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Apparmor blocks Torbrowser downloads
Torbrower no longer asks where to download even though that option is
enabled in its settings.
Torbrowser no longer can download a file to my home directory ("Could
not read the contents of ...)". I get impression that apparmor is
preventing a download to where I want. So I put the line:
owner "@{HOME/" rw,
into /etc/apparmor.d/torbrowser.Tor.tor . This has no effect.
I also ran to no effect:
$ sudo sh -c 'echo "owner /dev/shm/wayland.mozilla.ipc.[0-9]* rw," >
/etc/apparmor.d/local/torbrowser.Browser.firefox ; apparmor_parser -r
/etc/apparmor.d/torbrowser.Browser.firefox'
The package apparmor-profile-torbrowser is not in Chimaera rspository.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
