This problem actually occurs with all the ACPI-enabled kernels I have tried. Most recent kernel where this bug did *NOT* occur: Distribution: Ubuntu 7.04 development packages Fedora Core 7 development packages Hardware Environment: Software Environment: Problem Description: Lid button triggers suspend only every other attempt. Steps to reproduce: Close the lid. The first time after booting, the machine suspends. The second time, it fails. Then it works, etc.
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.