breakage in current git-acpi

DISCUSSION Andrew Morton 3 participants 8 messages Feb 17, 2007 – Feb 25, 2007 ACPI

Share & tools

Andrew Morton

author

2007-02-17 06:41 UTC #0 lore raw

Standard FC5 RH install, it is set up to suspend to disk when I close the lid.

With git-acpi.patch applied, this just stops working on the second or third attempt. It's like acpid just didn't see the lid close at all. Closing the lid causes no kernel messages at all.

Any suggestions as to how to debug this, apart from git-bisect, which will take rather a long time?

Len Brown

reviewer

2007-02-17 07:26 UTC #1 lore raw

Quoted 10 lines · Andrew Morton

Standard FC5 RH install, it is set up to suspend to disk when I close the lid.
With git-acpi.patch applied, this just stops working on the second or third attempt. It's like acpid just didn't see the lid close at all. Closing the lid causes no kernel messages at all.
Any suggestions as to how to debug this, apart from git-bisect, which will take rather a long time?

nuke kacpid and cat /proc/acpi/event

click the lid a bunch of times and also the power button you should see the acpi line in /proc/interrupts tick each time, and a message come out of /proc/acpi/event

Also, you should be able to see the state of the lid in a file under /proc/acpi/button/*/

-Len

Andrew Morton

author

2007-02-17 07:51 UTC #2 lore raw

Quoted 5 lines · On Sat, 17 Feb 2007 02:25:07 -0500 Len Brown <[email protected]> wrote:

Quoted 4 lines · Andrew Morton
Standard FC5 RH install, it is set up to suspend to disk when I close the lid.

Quoted 8 lines

Quoted 6 lines
With git-acpi.patch applied, this just stops working on the second or third attempt. It's like acpid just didn't see the lid close at all. Closing the lid causes no kernel messages at all.
Any suggestions as to how to debug this, apart from git-bisect, which will take rather a long time?
nuke kacpid

I hope you meant acpid - I can't kill a kernel thread ;)

Quoted 3 lines

and cat /proc/acpi/event
click the lid a bunch of times

sony:/home/akpm# cat /proc/acpi/event
button/lid LID0 00000080 00000005
button/lid LID0 00000080 00000006
button/lid LID0 00000080 00000007
button/lid LID0 00000080 00000008

Quoted 1 line

and also the power button

button/power PWRB 00000080 00000001 button/power PWRB 00000080 00000002 button/power PWRB 00000080 00000003 button/power PWRB 00000080 00000004

Quoted 2 lines

you should see the acpi line in /proc/interrupts tick each time, and a message come out of /proc/acpi/event

yup.

9: 1344 IO-APIC-fasteoi acpi

it's increasing even while the machine is just sitting there.

Quoted 1 line

Also, you should be able to see the state of the lid in a file under /proc/acpi/button/*/

sony:/home/akpm# cat /proc/acpi/button/lid/LID0/state
state:      closed
sony:/home/akpm# cat /proc/acpi/button/lid/LID0/state
state:      open

all seems well.

Stopping and restarting acpid doesn't fix it.

Len Brown

reviewer

2007-02-18 02:57 UTC #3 lore raw

Quoted 11 lines · Andrew Morton

Quoted 9 lines · On Sat, 17 Feb 2007 02:25:07 -0500 Len Brown <[email protected]> wrote:
Quoted 8 lines · Andrew Morton
Standard FC5 RH install, it is set up to suspend to disk when I close the lid.
With git-acpi.patch applied, this just stops working on the second or third attempt. It's like acpid just didn't see the lid close at all. Closing the lid causes no kernel messages at all.

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
Any suggestions as to how to debug this, apart from git-bisect, which will take rather a long time?
nuke kacpid
I hope you meant acpid - I can't kill a kernel thread ;)

right -- this is why I don't try to cut code at 3am;-)

Quoted 11 lines

Quoted 3 lines

and cat /proc/acpi/event
click the lid a bunch of times

sony:/home/akpm# cat /proc/acpi/event
button/lid LID0 00000080 00000005
button/lid LID0 00000080 00000006
button/lid LID0 00000080 00000007
button/lid LID0 00000080 00000008

Quoted 9 lines

Quoted 1 line
and also the power button
button/power PWRB 00000080 00000001 button/power PWRB 00000080 00000002 button/power PWRB 00000080 00000003 button/power PWRB 00000080 00000004
Quoted 2 lines
you should see the acpi line in /proc/interrupts tick each time, and a message come out of /proc/acpi/event

Assuming there is exactly 1 event for each press,
then the kernel part of this is healthy.

Assuming the failure is that the lid event fails to trigger the STD after a few iterations, and you did this after the failure started; then it seems the failure isn't the event at all, but perhaps the inability to re-invoke STD.

What happens if you invoke STD manually with

# echo disk > /sys/power/state

Quoted 3 lines

9: 1344 IO-APIC-fasteoi acpi
it's increasing even while the machine is just sitting there.

That's okay -- it is common -- particularly
laptops, which are likely to have a number of events ticking away. thermal and fan control, and battery state, in particular.

Quoted 10 lines

Quoted 1 line
Also, you should be able to see the state of the lid in a file under /proc/acpi/button/*/
sony:/home/akpm# cat /proc/acpi/button/lid/LID0/state
state:      closed
sony:/home/akpm# cat /proc/acpi/button/lid/LID0/state
state:      open
all seems well.
Stopping and restarting acpid doesn't fix it.

Yeah, it must be suspend-to-disk itself refusing to suspend. Probably when automatically invoked any errors or warnings get sent to /dev/null.
Are there any dmesg associated with the failed suspend attempt?

How many suspend cycles can you survive before git-acpi is applied?

-Len

Andrew Morton

author

2007-02-18 03:09 UTC #4 lore raw

Quoted 4 lines · On Sat, 17 Feb 2007 21:59:02 -0500 Len Brown <[email protected]> wrote:

Assuming there is exactly 1 event for each press,
then the kernel part of this is healthy.

Quoted 8 lines

Assuming the failure is that the lid event fails to trigger the STD after a few iterations, and you did this after the failure started; then it seems the failure isn't the event at all, but perhaps the inability to re-invoke STD.
What happens if you invoke STD manually with
# echo disk > /sys/power/state

That works OK.

Quoted 15 lines

Quoted 3 lines
9: 1344 IO-APIC-fasteoi acpi
it's increasing even while the machine is just sitting there.
That's okay -- it is common -- particularly
laptops, which are likely to have a number of events ticking away. thermal and fan control, and battery state, in particular.
Quoted 7 lines
Quoted 1 line
Also, you should be able to see the state of the lid in a file under /proc/acpi/button/*/
sony:/home/akpm# cat /proc/acpi/button/lid/LID0/state
state:      closed
sony:/home/akpm# cat /proc/acpi/button/lid/LID0/state
state:      open

Quoted 8 lines

Quoted 3 lines
all seems well.
Stopping and restarting acpid doesn't fix it.
Yeah, it must be suspend-to-disk itself refusing to suspend. Probably when automatically invoked any errors or warnings get sent to /dev/null.
Are there any dmesg associated with the failed suspend attempt?

No messages come out when I shut the lid.

Manually suspending works normally.

Quoted 1 line

How many suspend cycles can you survive before git-acpi is applied?

I tested up to five or six times once.

Andrew Morton

author

2007-02-25 08:55 UTC #5 lore raw

Quoted 42 lines · On Sat, 17 Feb 2007 19:07:55 -0800 Andrew Morton <[email protected]>…

Quoted 4 lines · On Sat, 17 Feb 2007 21:59:02 -0500 Len Brown <[email protected]> wrote:
Assuming there is exactly 1 event for each press,
then the kernel part of this is healthy.
Quoted 8 lines
Assuming the failure is that the lid event fails to trigger the STD after a few iterations, and you did this after the failure started; then it seems the failure isn't the event at all, but perhaps the inability to re-invoke STD.
What happens if you invoke STD manually with
# echo disk > /sys/power/state
That works OK.
Quoted 15 lines
Quoted 3 lines
9: 1344 IO-APIC-fasteoi acpi
it's increasing even while the machine is just sitting there.
That's okay -- it is common -- particularly
laptops, which are likely to have a number of events ticking away. thermal and fan control, and battery state, in particular.
Quoted 7 lines
Quoted 1 line
Also, you should be able to see the state of the lid in a file under /proc/acpi/button/*/
sony:/home/akpm# cat /proc/acpi/button/lid/LID0/state
state:      closed
sony:/home/akpm# cat /proc/acpi/button/lid/LID0/state
state:      open
Quoted 8 lines
Quoted 3 lines
all seems well.
Stopping and restarting acpid doesn't fix it.
Yeah, it must be suspend-to-disk itself refusing to suspend. Probably when automatically invoked any errors or warnings get sent to /dev/null.
Are there any dmesg associated with the failed suspend attempt?

Quoted 7 lines

No messages come out when I shut the lid.
Manually suspending works normally.
Quoted 1 line
How many suspend cycles can you survive before git-acpi is applied?
I tested up to five or six times once.

So.. I went from 2.6.20-mm1 back to 2.6.21-rc1 the other day and have since been happily suspending via lid closure maybe ten times a day.

Any more suggestions about how to debug this?

How does the suspend happen, anyway? Is it acpid's job to read the LID0/state file and to then poke /sys/power/state? Or is that linkage in-kernel?

Alexey Starikovskiy

2007-02-25 14:21 UTC #6 lore raw

Quoted 54 lines · Andrew Morton

Quoted 44 lines · On Sat, 17 Feb 2007 19:07:55 -0800 Andrew Morton <[email protected]>…
Quoted 12 lines · On Sat, 17 Feb 2007 21:59:02 -0500 Len Brown <[email protected]> wrote:
Assuming there is exactly 1 event for each press,
then the kernel part of this is healthy.
Assuming the failure is that the lid event fails to trigger the STD after a few iterations, and you did this after the failure started; then it seems the failure isn't the event at all, but perhaps the inability to re-invoke STD.
What happens if you invoke STD manually with
# echo disk > /sys/power/state
That works OK.
Quoted 16 lines
Quoted 4 lines
9: 1344 IO-APIC-fasteoi acpi
it's increasing even while the machine is just sitting there.
That's okay -- it is common -- particularly
laptops, which are likely to have a number of events ticking away. thermal and fan control, and battery state, in particular.
Quoted 7 lines
Quoted 2 lines
Also, you should be able to see the state of the lid in a file under /proc/acpi/button/*/
sony:/home/akpm# cat /proc/acpi/button/lid/LID0/state
state:      closed
sony:/home/akpm# cat /proc/acpi/button/lid/LID0/state
state:      open
Quoted 9 lines
Quoted 4 lines
all seems well.
Stopping and restarting acpid doesn't fix it.
Yeah, it must be suspend-to-disk itself refusing to suspend. Probably when automatically invoked any errors or warnings get sent to /dev/null.
Are there any dmesg associated with the failed suspend attempt?
Quoted 9 lines
No messages come out when I shut the lid.
Manually suspending works normally.
Quoted 2 lines
How many suspend cycles can you survive before git-acpi is applied?
I tested up to five or six times once.

Quoted 9 lines

So.. I went from 2.6.20-mm1 back to 2.6.21-rc1 the other day and have since been happily suspending via lid closure maybe ten times a day.
Any more suggestions about how to debug this?
How does the suspend happen, anyway? Is it acpid's job to read the LID0/state file and to then poke /sys/power/state? Or is that linkage in-kernel?

It is done by userspace utilities, either acpid (if there is action /etc/acpid/) or hald and desktop... Last changes to buttons was export their events into input layer. May by this confuses hald which can see same event twice -- once from acpid and the other from input layer...
button.c sends event into /proc/acpi/events and _now_ into input layer
acpid reads /proc/acpi/events and either performs action from /etc/acpid or sends them higher (hald) someone reads event from input layer or hald and then writes into /sys/power/state...
The patch to insert input layer into buttons is from Dmitry Torokhov, may be he can give some more explanations... May be you could revert the patch in question and see if it helps. It is not dependent to any other ACPI changes.

Regards,
Alex.

Alexey Starikovskiy

2007-02-25 14:44 UTC #7 lore raw

In reply to Andrew Morton

Quoted 59 lines · Andrew Morton

Quoted 44 lines · On Sat, 17 Feb 2007 19:07:55 -0800 Andrew Morton <[email protected]>…
Quoted 12 lines · On Sat, 17 Feb 2007 21:59:02 -0500 Len Brown <[email protected]> wrote:
Assuming there is exactly 1 event for each press,
then the kernel part of this is healthy.
Assuming the failure is that the lid event fails to trigger the STD after a few iterations, and you did this after the failure started; then it seems the failure isn't the event at all, but perhaps the inability to re-invoke STD.
What happens if you invoke STD manually with
# echo disk > /sys/power/state
That works OK.
Quoted 16 lines
Quoted 4 lines
9: 1344 IO-APIC-fasteoi acpi
it's increasing even while the machine is just sitting there.
That's okay -- it is common -- particularly
laptops, which are likely to have a number of events ticking away. thermal and fan control, and battery state, in particular.
Quoted 7 lines
Quoted 2 lines
Also, you should be able to see the state of the lid in a file under /proc/acpi/button/*/
sony:/home/akpm# cat /proc/acpi/button/lid/LID0/state
state:      closed
sony:/home/akpm# cat /proc/acpi/button/lid/LID0/state
state:      open
Quoted 9 lines
Quoted 4 lines
all seems well.
Stopping and restarting acpid doesn't fix it.
Yeah, it must be suspend-to-disk itself refusing to suspend. Probably when automatically invoked any errors or warnings get sent to /dev/null.
Are there any dmesg associated with the failed suspend attempt?
Quoted 9 lines
No messages come out when I shut the lid.
Manually suspending works normally.
Quoted 2 lines
How many suspend cycles can you survive before git-acpi is applied?
I tested up to five or six times once.
So.. I went from 2.6.20-mm1 back to 2.6.21-rc1 the other day and have since been happily suspending via lid closure maybe ten times a day.
Any more suggestions about how to debug this?

Quoted 8 lines

How does the suspend happen, anyway? Is it acpid's job to read the LID0/state file and to then poke /sys/power/state? Or is that linkage in-kernel?
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Also, it is worth checking that /proc/acpi/events sends same events in 2.6.21-rc1 and 2.6.20-mm1 for lid button...