FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 11-20-2011, 08:08 PM
Erik Johnson
 
Default 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
 
Old 11-20-2011, 08:14 PM
Alexander van den Berghe
 
Default 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
 
Old 11-20-2011, 08:16 PM
Alex Ferrando
 
Default 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
 
Old 11-20-2011, 08:23 PM
Leonid Isaev
 
Default 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
 
Old 11-20-2011, 08:35 PM
Carlchristian Eckert
 
Default 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)
 
Old 11-20-2011, 08:59 PM
Marek Otahal
 
Default 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 )
 
Old 11-20-2011, 09:35 PM
Manolo Martínez
 
Default 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...
--
 
Old 11-21-2011, 01:51 AM
Erik Johnson
 
Default 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
 
Old 11-21-2011, 01:57 AM
Erik Johnson
 
Default 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
 
Old 11-21-2011, 02:55 AM
Erik Johnson
 
Default 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.000000000 -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"
;;
 

Thread Tools




All times are GMT. The time now is 06:40 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org