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
11-20-2011, 08:14 PM
Alexander van den Berghe
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
11-20-2011, 08:16 PM
Alex Ferrando
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?
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.
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)
11-20-2011, 08:59 PM
Marek Otahal
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 )
11-20-2011, 09:35 PM
Manolo Martínez
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...
--
11-21-2011, 01:51 AM
Erik Johnson
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?
"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
11-21-2011, 01:57 AM
Erik Johnson
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.
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
11-21-2011, 02:55 AM
Erik Johnson
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.
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
ACPI bug in kernel 3.1?
)
