Re: [arch-general] ACPI bug in kernel 3.1?
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.
Re: [arch-general] ACPI bug in kernel 3.1?
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 pgpMARA9tQQir.pgp Description: PGP signature
Re: [arch-general] ACPI bug in kernel 3.1?
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 --- handler.sh 2011-10-07 14:17:32.0 -0500 +++ handler.sh.new 2011-11-20 21:46:57.131827682 -0600 @@ -57,8 +57,15 @@ esac ;; button/lid) -#echo "LID switched!">/dev/tty5 -;; + case "$3" in + close) + #echo "LID opened!">/dev/tty5 + ;; + open) + #echo "LID closed!">/dev/tty5 + ;; + esac + ;; *) logger "ACPI group/action undefined: $1 / $2" ;; pgpnPQAGNKoLF.pgp Description: PGP signature
Re: [arch-general] ACPI bug in kernel 3.1?
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 pgpF1c6LAR729.pgp Description: PGP signature
Re: [arch-general] ACPI bug in kernel 3.1?
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.html -- 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 pgpXAdNLKVAET.pgp Description: PGP signature
Re: [arch-general] ACPI bug in kernel 3.1?
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... --
Re: [arch-general] ACPI bug in kernel 3.1?
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) signature.asc Description: This is a digitally signed message part.
Re: [arch-general] ACPI bug in kernel 3.1?
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)
Re: [arch-general] ACPI bug in kernel 3.1?
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 pgpMQswZsSyCX.pgp Description: PGP signature
Re: [arch-general] ACPI bug in kernel 3.1?
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.html -- Alex Ferrando
Re: [arch-general] ACPI bug in kernel 3.1?
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
[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 pgpZhiewg7tUb.pgp Description: PGP signature
