[arch-general] ACPI bug in kernel 3.1?
Since the 3.1 update, when I suspend with pm-suspend, upon resuming my netbook goes right back to sleep. This behavior is not present in 3.0.7-1 but exists in 3.1-4 and 3.1.1-1. However, this only happens when my netbook is suspended via a lid close event. Running pm-suspend from the command line works as expected. I'm not using a DE. Suspend is triggered by adding /usr/sbin/pm-suspend to the "button/lid" action in /etc/acpi/handler.sh. This seems like an upstream bug, but I just wanted to see if anyone else was experiencing this. -- -Erik "For me, it is far better to grasp the universe as it really is than to persist in delusion, however satisfying and reassuring." --Carl Sagan
On 11/20/2011 10:08 PM, Erik Johnson wrote:
Since the 3.1 update, when I suspend with pm-suspend, upon resuming my netbook goes right back to sleep. This behavior is not present in 3.0.7-1 but exists in 3.1-4 and 3.1.1-1. However, this only happens when my netbook is suspended via a lid close event. Running pm-suspend from the command line works as expected.
I'm not using a DE. Suspend is triggered by adding /usr/sbin/pm-suspend to the "button/lid" action in /etc/acpi/handler.sh.
This seems like an upstream bug, but I just wanted to see if anyone else was experiencing this.
I am experiencing the same behaviour as you. But due to lack of time I haven't been able to dig into it. Alex
On 20/11/11 22:14, Alexander van den Berghe wrote:
On 11/20/2011 10:08 PM, Erik Johnson wrote:
Since the 3.1 update, when I suspend with pm-suspend, upon resuming my netbook goes right back to sleep. This behavior is not present in 3.0.7-1 but exists in 3.1-4 and 3.1.1-1. However, this only happens when my netbook is suspended via a lid close event. Running pm-suspend from the command line works as expected.
I'm not using a DE. Suspend is triggered by adding /usr/sbin/pm-suspend to the "button/lid" action in /etc/acpi/handler.sh.
This seems like an upstream bug, but I just wanted to see if anyone else was experiencing this.
I am experiencing the same behaviour as you. But due to lack of time I haven't been able to dig into it.
Alex
Have you taken into consideration the deprecation of the old /proc interface for acpi? https://mailman.archlinux.org/pipermail/arch-dev-public/2011-October/021829.... -- Alex Ferrando
On (11/20/11 22:14), Alexander van den Berghe wrote: -~> On 11/20/2011 10:08 PM, Erik Johnson wrote: -~> >Since the 3.1 update, when I suspend with pm-suspend, upon resuming my -~> >netbook goes right back to sleep. This behavior is not present in -~> >3.0.7-1 but exists in 3.1-4 and 3.1.1-1. However, this only happens when -~> >my netbook is suspended via a lid close event. Running pm-suspend from -~> >the command line works as expected. -~> > -~> >I'm not using a DE. Suspend is triggered by adding /usr/sbin/pm-suspend -~> >to the "button/lid" action in /etc/acpi/handler.sh. -~> > -~> >This seems like an upstream bug, but I just wanted to see if anyone else -~> >was experiencing this. -~> > -~> -~> I am experiencing the same behaviour as you. But due to lack of -~> time I haven't been able to dig into it. -~> -~> Alex If plain pm-suspend works fine, this means that the lid close event is triggered twice: on close and open. You can verify whether it is true by replacing pm-suspend with logger "Some message" in handler.sh and see if there are two messages in /var/log/messages. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
If plain pm-suspend works fine, this means that the lid close event is triggered twice: on close and open. You can verify whether it is true by replacing pm-suspend with logger "Some message" in handler.sh and see if there are two messages in /var/log/messages.
Yes, I get actually exactly this behaviour since the last update. Two messages and sleep is obviously triggered twice (manual pm-suspend works fine)
On Sunday 20 of November 2011 15:08:54 Erik Johnson wrote:
Since the 3.1 update, when I suspend with pm-suspend, upon resuming my netbook goes right back to sleep. This behavior is not present in 3.0.7-1 but exists in 3.1-4 and 3.1.1-1. However, this only happens when my netbook is suspended via a lid close event. Running pm-suspend from the command line works as expected.
I'm not using a DE. Suspend is triggered by adding /usr/sbin/pm-suspend to the "button/lid" action in /etc/acpi/handler.sh.
This seems like an upstream bug, but I just wanted to see if anyone else was experiencing this.
I have similar issues, upgraded to 3.1 and stuff and now pm-hibernate stopped working for me. The command ends with $? = 0 but nothing at all happens. Will try to investigate more but i was thinking about the new udev and some removed rules from that..? -- Marek Otahal :o)
On 11/20/11 at 11:35pm, Carlchristian Eckert wrote:
If plain pm-suspend works fine, this means that the lid close event is triggered twice: on close and open. You can verify whether it is true by replacing pm-suspend with logger "Some message" in handler.sh and see if there are two messages in /var/log/messages.
Yes, I get actually exactly this behaviour since the last update. Two messages and sleep is obviously triggered twice (manual pm-suspend works fine) Same here... --
On Sun, Nov 20, 2011 at 10:16:36PM +0100, Alex Ferrando wrote:
Have you taken into consideration the deprecation of the old /proc interface for acpi?
https://mailman.archlinux.org/pipermail/arch-dev-public/2011-October/021829....
-- Alex Ferrando
handler.sh uses /sys on my netbook. -- -Erik "For me, it is far better to grasp the universe as it really is than to persist in delusion, however satisfying and reassuring." --Carl Sagan
On Sun, Nov 20, 2011 at 03:23:16PM -0600, Leonid Isaev wrote:
If plain pm-suspend works fine, this means that the lid close event is triggered twice: on close and open. You can verify whether it is true by replacing pm-suspend with logger "Some message" in handler.sh and see if there are two messages in /var/log/messages.
-- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
I had suspected that this was the case, but didn't have time to test before writing my initial email. I've confirmed this behavior on my netbook as well. ejohnson@tardis:~% grep testacpid /var/log/everything.log Nov 20 20:53:32 localhost testacpid: button/lid triggered Nov 20 20:53:48 localhost testacpid: button/lid triggered -- -Erik "For me, it is far better to grasp the universe as it really is than to persist in delusion, however satisfying and reassuring." --Carl Sagan
On Sun, Nov 20, 2011 at 08:57:31PM -0600, Erik Johnson wrote:
On Sun, Nov 20, 2011 at 03:23:16PM -0600, Leonid Isaev wrote:
If plain pm-suspend works fine, this means that the lid close event is triggered twice: on close and open. You can verify whether it is true by replacing pm-suspend with logger "Some message" in handler.sh and see if there are two messages in /var/log/messages.
-- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
I had suspected that this was the case, but didn't have time to test before writing my initial email. I've confirmed this behavior on my netbook as well.
ejohnson@tardis:~% grep testacpid /var/log/everything.log Nov 20 20:53:32 localhost testacpid: button/lid triggered Nov 20 20:53:48 localhost testacpid: button/lid triggered
OK, I believe I have found why. I ran acpi_listen before closing the lid, and observed the following: button/lid LID close button/lid LID open Both events match "button/lid" in the case statement in handler.sh. I took the default handler.sh from the acpid package and modified it so that it checks the 3rd argument passed to handler.sh for "close" or "open". I then added /usr/sbin/pm-suspend to the "close" section of the newly-added case statement, tested, and confirmed that this fixed the problem. Patch attached. Will file a bug in flyspray. -- -Erik "For me, it is far better to grasp the universe as it really is than to persist in delusion, however satisfying and reassuring." --Carl Sagan
On Sun, Nov 20, 2011 at 09:55:22PM -0600, Erik Johnson wrote:
OK, I believe I have found why. I ran acpi_listen before closing the lid, and observed the following:
button/lid LID close button/lid LID open
Both events match "button/lid" in the case statement in handler.sh. I took the default handler.sh from the acpid package and modified it so that it checks the 3rd argument passed to handler.sh for "close" or "open". I then added /usr/sbin/pm-suspend to the "close" section of the newly-added case statement, tested, and confirmed that this fixed the problem.
Patch attached. Will file a bug in flyspray.
I just realized that I reversed the lines in the commented-out messages in the part that I added. Derp. Oh well. Bug report filed. Link for those who want to follow: https://bugs.archlinux.org/task/27201 -- -Erik "For me, it is far better to grasp the universe as it really is than to persist in delusion, however satisfying and reassuring." --Carl Sagan
Excerpts from Erik Johnson's message of 2011-11-20 22:08:54 +0100:
Since the 3.1 update, when I suspend with pm-suspend, upon resuming my netbook goes right back to sleep. This behavior is not present in 3.0.7-1 but exists in 3.1-4 and 3.1.1-1. However, this only happens when my netbook is suspended via a lid close event. Running pm-suspend from the command line works as expected.
I'm not using a DE. Suspend is triggered by adding /usr/sbin/pm-suspend to the "button/lid" action in /etc/acpi/handler.sh.
This seems like an upstream bug, but I just wanted to see if anyone else was experiencing this.
I have a different but possibly related problem since a few days. Sometimes when I shutdown, the laptop reboots instead. Where that comes from I have no idea.
participants (8)
-
Alex Ferrando
-
Alexander van den Berghe
-
Carlchristian Eckert
-
Erik Johnson
-
Leonid Isaev
-
Manolo Martínez
-
Marek Otahal
-
Philipp Überbacher