Bug 8285

http://bugzilla.kernel.org/attachment.cgi?id=10990&action=view
http://bugzilla.kernel.org/attachment.cgi?id=10991&action=view
http://bugzilla.kernel.org/attachment.cgi?id=10996&action=view
http://bugzilla.kernel.org/attachment.cgi?id=10997&action=view

stop acpid first and #cat /proc/acpi/event
Open and close the lid for several times,
See if there is an event pop up every time you close/open the lid.
Attach the output here as well. :)

Yes.  For each press of the lid button, there were two events (I would assume
that the first is interpreted as a Close and the second as an Open event.  It
seems as though the code for the press and release events are the same, which is
odd.

FractalPath:~# cat /proc/acpi/event 
button/lid LID0 00000080 00000001
button/lid LID0 00000080 00000002
button/lid LID0 00000080 00000003
button/lid LID0 00000080 00000004
button/lid LID0 00000080 00000005
button/lid LID0 00000080 00000006
button/lid LID0 00000080 00000007
button/lid LID0 00000080 00000008
button/lid LID0 00000080 00000009
button/lid LID0 00000080 0000000a
button/lid LID0 00000080 0000000b
button/lid LID0 00000080 0000000c
button/lid LID0 00000080 0000000d
button/lid LID0 00000080 0000000e
button/lid LID0 00000080 0000000f
button/lid LID0 00000080 00000010
button/lid LID0 00000080 00000011
button/lid LID0 00000080 00000012
button/lid LID0 00000080 00000013
button/lid LID0 00000080 00000014

>For each press of the lid button, there were two events (I would assume
>that the first is interpreted as a Close and the second as an Open event.  It
>seems as though the code for the press and release events are the same,
>which is odd.
It's ok.
Notify 0x80 is used to tell the device that the lid status has changed.

Created attachment 11138 [details]
debug dsdt

Hi, Miles
Can you try the debug dsdt I attached?
Hope it can bring more information we need. :)
Do the same test and attach the _dmesg_ output.

I will test as you request shortly.

FWIW, with the latest 2.6.21-rc6-mm1, the behavior is a little different (worse).
Now, pressing the lid button _never_ triggers a suspend.  Also, if I trigger the
suspend from the Gnome Quit dialog, the machine seems to go through the suspend
process (I see disk activity), but the power doesn't actually suspend (the power
button doesn't start blinking) until I touch the touchpad.  This seems to be a
new bug in the MM tree.  I will follow up with Andrew separately.

Hmm.  Can you give me instructions on how to test your attached dsdt?  I looked
at http://www.intel.com/technology/iapc/acpi/bios_override.htm, but it doesn't
look straightforward at all.

Thanks!

First set CONFIG_ACPI_CUSTOM_DSDT.
Then set the next option CONFIG_ACPI_CUSTOM_DSDT_FILE with the full path name 
to the new dsdt.hex file.

So, something like this?

In /usr/src/linux:
1. Download attachment.cgi.
2. mv attachment.cgi /usr/src/linux/dsdt.hex
3. make clean
4. export CONFIG_ACPI_CUSTOM_DSDT
5. export CONFIG_ACPI_CUSTOM_DSDT_FILE=/usr/src/linux/dsdt.hex
6. make all install modules modules_install
7. mkinitramfs -o /boot/initrd.img-2.6.20 2.6.20
8. update-grub

Just setting those environment variables doesn't seem to cause make to rebuild
the ACPI files, so it seems a clean build is needed.  mrproper isn't required?

Could you tell me what I should look for in the dmesg output, so that I can tell
whether I have successfully built with your debug code getting used?

Thanks.

Another question:  the file you attached is an ASCII file, but you mention
dsdt.hex.  Do I need to take the ASCII file and then compile dsdt.hex from it?
Sorry this is taking so long.

Created attachment 11161 [details]
dmesg output -- I suspended and resumed a couple of times.

I reproduced the problem a couple of times.  With four attempted suspends, I
only got the first and third to succeed.  Hopefully, I have gotten your
debugging dsdt to be used and the dmesg output will be helpful.  In addition to
recompiling the kernel with the environment variables set, I tried passing the
flag and variable as kernel boot arguments.  I put a copy of the dsdt file in
/DSDT.aml, because I saw a boot message saying that this was expected.

Created attachment 11162 [details]
Another dmesg -- 2.6.20 

I have been trying changing the kernel boot options to see if it changes what
happens.  I tried pci=routirq and pci=biosirq.	Also, I find that suspend is
really busted on this machine with 2.6.21-rc7.	Stuff hangs (touching the
mousepad causes things to unfreeze momentarily), etc.  I decided to try
focusing on 2.6.20, since it demonstrates the bahavior described in this bug
report.  Newer kernels seem much more broken, in general.

Not sure what caused this:

[ 1211.533000] ACPI: EC: acpi_ec_wait timeout, status = 0, expect_event = 1
[ 1211.533000] ACPI: EC: read timeout, command = 128
[ 1211.533000] ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for
[EmbeddedControl] [20060707]
[ 1211.533000] ACPI Exception (dswexec-0458): AE_TIME, While resolving operands
for [Store] [20060707]
[ 1211.533000] ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.ACAD._PSR] (Node dfc87464), AE_TIME
[ 1211.536000] ACPI Exception (acpi_ac-0096): AE_TIME, Error reading AC Adapter
state [20060707]
[ 1230.065000] ACPI: EC: acpi_ec_wait timeout, status = 0, expect_event = 1
[ 1230.065000] ACPI: EC: read timeout, command = 128
[ 1230.065000] ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for
[EmbeddedControl] [20060707]
[ 1230.065000] ACPI Exception (dswexec-0458): AE_TIME, While resolving operands
for [Store] [20060707]
[ 1230.065000] ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.BAT0.UPBS] (Node dfc879c4), AE_TIME
[ 1230.068000] ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.BAT0._BST] (Node dfc87624), AE_TIME
[ 1230.069000] ACPI Exception (acpi_battery-0207): AE_TIME, Evaluating _BST
[20060707]
[ 1233.199000] ACPI: EC: acpi_ec_wait timeout, status = 0, expect_event = 1
[ 1233.199000] ACPI: EC: read timeout, command = 128
[ 1233.199000] ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for
[EmbeddedControl] [20060707]
[ 1233.199000] ACPI Exception (dswexec-0458): AE_TIME, While resolving operands
for [And] [20060707]
[ 1233.199000] ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.PCI0.LPCB.H_EC.SMRD] (Node dfc8cca4), AE_TIME
[ 1233.202000] ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.BAT0.UPBI] (Node dfc87604), AE_TIME
[ 1233.202000] ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.BAT0._BIF] (Node dfc87644), AE_TIME
[ 1233.203000] ACPI Exception (acpi_battery-0148): AE_TIME, Evaluating _BIF
[20060707]

>Hopefully, I have gotten your debugging dsdt
>to be used and the dmesg output will be helpful. 
Hmmm, I'm afraid not. :(

>7. mkinitramfs -o /boot/initrd.img-2.6.20 2.6.20
>8. update-grub
You don't have to do this, just follow the step 1,2,4,5,6 is OK. :)

Are you saying that I haven't got your debugging dsdt file to be used, or that I
am using it but the dmesg output isn't useful?  If I am not correctly building
so that the dsdt is used, please explain what I am doing wrong.   Thanks.

Created attachment 11164 [details]
debug dsdt

Well, I did not get any debug message I add in the new dsdt. :(
Would you please try this one?
PS: override dsdt is not that troublesome. I don't know what the problem is as
I'm not quite good at it. But I can successfully override my dsdt following the
steps 1,2,4,5,6 in comment#9. So will you please reverse the changes you made
and try again?
Thanks.

Created attachment 11222 [details]
Rebuilt with new dsdt.hex

Please let me know whether this indicates that I am actually using your new
dsdt information.  I don't see anything obvious.  Please, tell me what to look
for so that I can know that I have a working build using your code!

WIth this latest attempt, I ran "make clean" before exporting the variables and
doing the kernel build.  I removed the boottime arguments, since I thought that
perhaps this was messing up the use of your dsdt information.  You still haven't
really explained how this works, which leaves me floundering. 

I just located these instructions:
http://www.cs.uiowa.edu/~asignori/modify-dsdt.txt
Hopefully, this will work for me.

----------------------------
[G] Include DSDT.HEX in the kernel source code -------------------------
Copy the file DSDT.HEX in the directory

   driver/acpi/

of the last kernel source code. Then open with a text editor the file

   osl.c

somewhere before the lines

   #ifdef CONFIG_ACPI_CUSTOM_DSDT
      #include CONFIG_ACPI_CUSTOM_DSDT_FILE
   #endif

you have to write something like

   #define CONFIG_ACPI_CUSTOM_DSDT
   #define CONFIG_ACPI_CUSTOM_DSDT_FILE "dsdt.hex"

Then delete the file OSL.O if it exists and recompile your kernel.

Created attachment 11223 [details]
This one worked -- debug info is contained

I see the additional debugging information in this one.  I hope this helps.

Anyone able to look into this further?  I am available to test.

Hello, Miles,
Sorry for the delay. I'm on vacation last week. :)
As the events can be generated properly, it should be a user space problem.
Here is a test that should fix your problem:
Copy the lid.conf to /etc/acpi/events/,
Copy s3-script to /root/ and change its mode to 777,
Restart the acpid and try again.

Created attachment 11431 [details]
used by acpid when lid events occurs

Created attachment 11432 [details]
script to enter s3, which is needed by lid.conf

Okay, I tested this out on my Fedora installation (my Ubuntu development 
installation seems messed up right now).

The news isn't all good.
1.  The first attempt to suspend seems to work fine.  Then, when I open the 
lid, after resuming partially (the screen remains black), the machine 
resuspends.  When I press and release the lid button, the machine resumes, but 
the screen stays black.
2.  All subsequent attempts to suspend and resume all apparently succeed, aside 
from the screen remaining black.
3.  I attempted to find timing issues by beginning a resume and then quickly 
pressing the lid button again.  Once, after starting a resume, I pressed the 
lid button down after about three seconds and the machine never resuspended.

Hi, Miles,
I have something to verify.
First, pressing the lid used to suspend the system. But this doesn't work 
anymore since you update to 2.6.21-rc7 and applied David's patch, right?
This is really weird. Please make sure that you do the _same_ tests with the 
_same_ distribution.

Hello,

I can to the conclusion that my Ubuntu development installation was messed up,
so I have installed a clean Ubuntu 7.04 with updates.  Now I have discovered
that Ubuntu uses a different naming convention for the /etc/acpi/events config
files:
http://folk.ntnu.no/gronslet/blog/2005/06/03/linux-on-dell-x1/
Search for "DBG" and you'll find:
[Mon Jun 27 20:46:18 2005] DBG: ignoring conf file /etc/acpi/events/lid.conf
Which I discovered was occuring on my new Ubuntu installation.
Later on in the blog, it is mentioned:
    # mv lid.conf lid
    [Mon Jun 27 20:46:41 2005] DBG: parsing conf file /etc/acpi/events/lid
So, I renamed lid.conf to lid and I started getting reliable suspending, every
time, on Ubuntu 7.04.
The only problem I am seeing is that my Xorg cursor becomes invisible after the
first suspend/resume.  Restarting Xorg fixes that problem.  I can track down
that problem separately.
So, for Ubuntu, should I submit a bug report asking that they make the needed
changes?  Where should s3-script live?

I will try some more testing with Fedora 7.

Created attachment 11456 [details]
s3-script on my hp nx5000

The symptom on my hp nx5000 is a little different from yours.
The lid never triggers S3 suspend/resume.
I use this script and the lid.conf to make it suspend when closing the lid, and
manually wake it up by pressing the power button. :)
"vbetool post" is for the S3 video issue.
You can have a try. Just remember to replace the path name of lid state file.:)


PS: As the lid event can be generated properly. I don't think it's a
kernel/acpi problem.

>So, I renamed lid.conf to lid and I started getting reliable suspending,
>every time, on Ubuntu 7.04.
Oh, great news. :)
Please ignore my comment #27.

>So, for Ubuntu, should I submit a bug report asking that they make the
>needed changes?
Emm, I'm not sure. :)

> Where should s3-script live?
you can replace the "action=/root/s3-script" with "action=echo mem 
>/sys/power/state" to get rid of the s3-script.

I read this:
http://acpi.sourceforge.net/documentation/sleep.html
I notice that we are doing some things differently than Windows.
The part that worries me is that in the kernel 2.4 approach, we default to S3
for suspend and Windows to S1.  We do this in spite of an explicit recognition
that S3 is more unstable and unreliable, due to the many, often buggy,
components involved.  Why did we not just go with S1?  I understand additional
power is saved, but is it worth having unreliable suspending in laptops?
Okay, now we have the 2.6 series with ACPI events.  I read the contents of
/sys/power/state and got only "mem disk".  No suspend.  I have tried using "mem"
to suspend the machine, as suggested.  It does reliably enter a suspend state. 
I don't know if it is S1, S2 or S3, but I suspect it is S3, since I am seeing a
lot of system instability (Xorg mouse cursor disappearing on resume, sometimes
the display stays completely blank, sometimes my system time gets out of whack).
 Is there a way for me to use ACPI/sysfs to enter S1, instead?  I would love for
S3 to work perfectly, but that isn't happening right now.  Still, I will read
the suggested documentation in my kernel source tree and see if I can resolve
all the problems.  One issue may be that I don't have the latest HAL.  Ubuntu
7.04 provides me hal 0.5.8.  I understand that hal 0.5.9 haa been backported,
but it hasn't been built and released yet.  Perhaps having hal 0.5.9 will help?

On my test box (the one I'm working on at the moment) 'cat /sys/power/state' shows

standby mem disk

where 'standby' is ACPI S1 and 'mem' is ACPI S3 ('disk' is the hibernation, but it is not ACPI S4).

If 'standby' is not shown on your box, this means that S1 is not supported on it.

BTW, can the bug be closed now?  If you think so, please close it.

Subject: Re:  HP dv1420us -- lid button triggers suspend only every other attempt

I will test later today.  Do I need to be running the latest mm
kernel, or is the latest Linus tree okay?

The Linus' tree is even better. :-)

(In reply to comment #31)
> I will test later today.  Do I need to be running the latest mm
> kernel, or is the latest Linus tree okay?

What was the result?

Okay, I'll check this.  Sorry for the delay.  I just moved to North Carolina and am very busy.

# cat /sys/power/state
mem disk

So, my machine doesn't support S1, eh?  Why is it that Windows XP "does the right thing" and always suspends when I close the lid and resumes when I open it?  It's been a while since I looked into this problem and I have lost the thread of the discussion.  I am running Ubuntu Gutsy now, and am back to the "only suspends on every other attempt" behavior.

I guess that linux-acpi is off the hook on this problem.  It seems, afaics, that:
S1 isn't supported on this machine
When I use "action=echo mem > /sys/power/state", my Xorg is crashing.
(I am currently testing with Ubuntu Gutsy and either 2.6.23-rc1-mm2 or linux-image-2.6.22-9-generic)
Any ideas why that is happening?

The bottom line is that using ACPI to manage suspending is broken on this machine.
:-(

I guess we can close this bug report, since the "suspends every other attempt" issue is not related to ACPI.

Man, suspending is just a major pain.  Xorg for "Intel Corporation 82852/855GM Integrated Graphics Device rev 2" seems to not be very happy with suspending.

So, it seems I need to figure out what system Ubuntu is using to suspend (APM?) and then report the (every other attempt) problem against that.