[Bug 1020965] New: Power management not working properly after upgrading from 13.2 to Tumblweed
http://bugzilla.opensuse.org/show_bug.cgi?id=1020965 Bug ID: 1020965 Summary: Power management not working properly after upgrading from 13.2 to Tumblweed Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: i586 OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Upgrade Problems Assignee: bnc-team-screening@forge.provo.novell.com Reporter: studio@anchev.net QA Contact: jsrain@suse.com Found By: --- Blocker: --- [I am putting this in component 'Upgrade Problems' because I don't know where exactly to put it. Please move it appropriately if necessary] After upgrading from 13.2 on my old 32 bit Acer TravelMate 2410 power management doesn't work as expected. I have always used acpid for the purpose of having the system hibernate automatically when the power is disconnected if the lid is closed and I have these settings and scripts for the purpose. These have always worked on 13.2 (in 'init 5' and in 'init 3' mode): # cat /etc/acpi/actions/hibernate.sh #!/bin/bash lockfile='/tmp/hibernation_started.lock' /usr/bin/logger 'AC power is off.' # Is hibernation already started? if [ -f "$lockfile" ] then /usr/bin/logger 'Hibernation already started.' exit 0 fi /usr/bin/touch $lockfile # Wait a bit (it may be just a short power off) sleep 30 # Is AC power still off? grep -q "off-line" /proc/acpi/ac_adapter/ADP1/state if [ $? = 0 ] then # Power is still off. Now check if laptop lid is closed grep -q closed /proc/acpi/button/lid/LID0/state if [ $? = 0 ] then /usr/bin/logger 'Initiating closed lid hibernation...' /usr/bin/rm $lockfile /usr/sbin/systemctl hibernate fi fi # cat /etc/acpi/actions/online.sh #!/bin/bash lockfile='/tmp/hibernation_started.lock' /usr/bin/logger 'AC power is on.' # Is hibernation already started? if [ -f "$lockfile" ] then /usr/bin/logger 'Cancelling closed lid hibernation.' /usr/bin/rm $lockfile fi # cat /etc/acpi/events/ac_power_off event=ac_adapter ACPI0003:00 00000080 00000000 action=/etc/acpi/actions/hibernate.sh # cat /etc/acpi/events/ac_power_on event=ac_adapter ACPI0003:00 00000080 00000001 action=/etc/acpi/actions/online.sh But now 'journalctl -f' is showing me a weird message when testing: Jan 17 01:01:27 acer.group systemd-logind[909]: Lid closed. Jan 17 01:01:35 acer.group root[3562]: AC power is off. Jan 17 01:01:35 acer.group systemd-udevd[3576]: Process '/usr/sbin/tlp auto' failed with exit code 4. Jan 17 01:02:46 acer.group systemd-udevd[3644]: Process '/usr/sbin/tlp auto' failed with exit code 4. (.... and the system doesn't hibernate... so I turn the power on again) Jan 17 01:02:46 acer.group root[3658]: AC power is on. Jan 17 01:02:46 acer.group root[3659]: Cancelling closed lid hibernation. Jan 17 01:02:52 acer.group root[3703]: AC power is off. Jan 17 01:02:52 acer.group systemd-udevd[3730]: Process '/usr/sbin/tlp auto' failed with exit code 4. And again - hibernation doesn't work. The bolded lines are something new (after upgrading to Tumbleweed). In 13.2 there were no such errors. Another attempt with acpid after rebooting (again) gives: Jan 17 01:38:17 acer.group root[2070]: AC power is off. (... no error like before but still not hibernating) Jan 17 01:39:22 acer.group root[2145]: AC power is on. Jan 17 01:39:22 acer.group root[2147]: Cancelling closed lid hiberna I am watching the 'journalctl -f' from an ssh session. I also tried manually evoking hibernation from xfce: Logout->Hibernate and through console (using 'systemclt hibernate') and it works. However when I power on the system again it is unusable - the power is on, the Tubmle weed 2-3 line version message appears after which the monitor turns off completely and the system doesn't react to anything I try - keyboard, mouse, touchpad, even ssh connection to it is impossible. The only way to get out of this is through hardware reset which is terrible. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1020965
http://bugzilla.opensuse.org/show_bug.cgi?id=1020965#c1
--- Comment #1 from George Anchev
http://bugzilla.opensuse.org/show_bug.cgi?id=1020965
http://bugzilla.opensuse.org/show_bug.cgi?id=1020965#c10
--- Comment #10 from Michal Suchanek
(In reply to Michal Suchanek from comment #8)
Yes. the file is now at /sys/class/power_supply/ACAD/online
You wrote the custom script so you are responsible for maintaining it across kernel versions. If you don't care to do it and want the script working don't upgrade to kernel versions that deprecate and remove the interface you use.
How can I know that such changes were made so that I can fix my scripts on time? a) follow kernel development b) strace a tool that gives the information you want like acpi(1) c) use the tool in the first place
Did you try to debug the suspend with console_no_suspend? I did not see any results of that posted here.
How do I do that? Where do I enter this option?
If you STFW for 'linux suspend debugging' you get lots of detailed information.
Either way, Tumbleweed tracks upstream closely in this regard so you should look for upstream instructions on debugging suspend issues and report upstream bug for it.
I am not sure I understand this part. Is this not the right place to report bugs? Please explain if I need to report something additional. Thanks.
You need to report what's broken on your system because you have the system so you are the only one who can find out. And you need to report it to upstream Linux developers so they can fix it and the fix gets to Tumbleweed through kernel updates. With Tumbleweed it's unlikely that this error is something SUSE specific. However, if workaround for this particular issue exists it can be applied in the suspend scripts. It would be nice to also report the bug number/git commit/workaround here so other openSUSE users know about it but it's not strictly necessary. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1020965
http://bugzilla.opensuse.org/show_bug.cgi?id=1020965#c11
--- Comment #11 from George Anchev
http://bugzilla.opensuse.org/show_bug.cgi?id=1020965
http://bugzilla.opensuse.org/show_bug.cgi?id=1020965#c12
--- Comment #12 from Michal Suchanek
No idea what the 'tlp auto' fail means and why it appears.
There is helpful 'cnf' command which tells you what package installs the command and you can read the package description then.
============================================================
Then I booted the system setting initcall_debug and no_console_suspend in GRUB on boot, like explained here (after doing the "STFW" step):
https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate... issues
After booting completed I ran:
# systemctl hibernate
The system powers off after a few seconds of hard disk activity. No any messages on screen, nothing showed in 'journalctl -f' while watching it through SSH. Pressing the power button doesn't restore from hibernate but instead boots through GRUB like from a shutdown state.
Obviously ssh will not work. If you are running X you might have better luck switching to text console. You might also want to increase loglevel.
After booting in the journal I read:
... Feb 16 18:40:01 acer systemd[1]: Starting Resume from hibernation using device /dev/sda1... Feb 16 18:40:01 acer systemd-hibernate-resume[284]: Could not resume from '/dev/sda1' (8:1). Feb 16 18:40:01 acer kernel: PM: Starting manual resume from disk Feb 16 18:40:01 acer kernel: PM: Hibernation image partition 8:1 present Feb 16 18:40:01 acer kernel: PM: Looking for hibernation image. Feb 16 18:40:01 acer kernel: PM: Image not found (code -22) Feb 16 18:40:01 acer kernel: PM: Hibernation image not present or could not be loaded.
This means a hibernation image was not created.
...
Trying the same thing without initcall_debug and no_console_suspend hibernates the system just like explained initially but upon powering it on the monitor is off, the system doesn't react to any key press or other event and trying to connect to it through SSH gives "No route to host". The only way to get out of this is hardware reset. ... Let me know if that information is enough for you to forward this upstream. If it is not - please provide steps for further debugging in layman terms (hopefully not using "STFW"). Thank you.
No, you did not diagnose why the system fails to resume nor did you provide kernel logs at which somebody could look. So there is no information to work with. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1020965
http://bugzilla.opensuse.org/show_bug.cgi?id=1020965#c13
--- Comment #13 from George Anchev
Obviously ssh will not work.
That's why I looked at the logs after rebooting and sent info about that.
If you are running X you might have better luck switching to text console. You might also want to increase loglevel.
All tests are made in runlevel 3.
This means a hibernation image was not created.
I understood that myself but thanks for confirming.
No, you did not diagnose why the system fails to resume nor did you provide kernel logs at which somebody could look. So there is no information to work with.
That's why there was also the next sentence:
If it is not (enough info) - please provide steps for further debugging in layman terms (hopefully not using "STFW"). Thank you.
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1020965
http://bugzilla.opensuse.org/show_bug.cgi?id=1020965#c14
Andreas Stieger
http://bugzilla.opensuse.org/show_bug.cgi?id=1020965
http://bugzilla.opensuse.org/show_bug.cgi?id=1020965#c15
--- Comment #15 from George Anchev
So from reading the report and comments this seems to have been a custom script, and the user needed to adjust it to match the new interfaces provided by the OS. Nothing further to do, closing as WONTFIX.
This is not resolved. I don't know why you mark it as such. You didn't even explain how to diagnose further. You just said "STFW" and then closed the ticket. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com