/proc/acpi/button/lid/*/state always says "open"

FYI, I also ran "tail -f /var/log/acpid".

When I do something like unplug the power adapter, I see plenty of output. But when I close or open the laptop lid, I don't see any new output.

Also, in terms of software versions:

"uname -a": Linux peace 2.6.20-9-generic #2 SMP Mon Feb 26 03:01:44 UTC 2007 i686 GNU/Linux

"dpkg -l hal": 0.5.8.1-4ubuntu8

"dpkg -l acpid": 1.0.4-5ubuntu5

"dpkg -l gnome-power-manager": 2.17.92-0ubuntu1

Note that this present bug is possibly the root cause of the following bug:
https://bugs.launchpad.net/ubuntu/+source/acpid/+bug/48471

I updated the laptop's BIOS to HP's latest, "F.17" and the bug is still manifest.

But is still present in the updated kernel, version
"2.6.20-11-generic #2 SMP Thu Mar 15 08:03:07 UTC 2007 i686 GNU/Linux"

I'd still say this is a BIOS bug. Does the laptop lid work under Windows?

I just tried it just now in Windows, and everything works correctly.

Windows does the right thing when the lid is closed. The screen fully
blanks (rather than just shutting off the back-light) and the laptop
sleeps, which is the action I specified in Control Panel -> Power
Options.

On 3/20/07, Ben Collins <email address hidden> wrote:
> I'd still say this is a BIOS bug. Does the laptop lid work under
> Windows?
>
> ** Changed in: linux-source-2.6.20 (Ubuntu)
> Assignee: (unassigned) => Ben Collins
> Status: Unconfirmed => Needs Info
>
> --
> /proc/acpi/button/lid/*/state always says "open"
> https://launchpad.net/bugs/89860
>

Fixed!!!

It seems to be fixed with one of today's updates, because I re-confirmed the bug a day or two after updating.

My kernel:
Linux peace 2.6.20-14-lowlatency #2 SMP PREEMPT Mon Apr 2 20:41:03 UTC 2007 i686 GNU/Linux

Actually, I don't think the kernel updated, so perhaps this fix came from some chance outside the kernel itself?

NOT FIXED!!!

*&^(*&^*% I don't know why, but it's back to the original, bad behavior. I've tried various suspends / hibernates / cold reboots, and I still can't get the /proc/acpi/.../state value to be "CLOSED" when the lid button is down. :(

This problem appears to be the root cause of my laptop's failure to hibernate on lid close. The settings appear right, and I can see that /etc/acpi/lid.sh is getting run. Adding debug echos to that script shows that /proc/acpi/button/lid/LID/state always gives "state: open".

As with Christian's case, I can successfully hibernate from menus, etc. - just not from lid close. This worked fine on Dapper for me, so seems to be some type of regression.

dmidecode output attached.

Regards,
Jeff Trull

Fixed in 2.6.22-12-generic (pre-release Gutsy).

Resume-from-suspend still has some issues, like the network interfaces disappear. But the regardless, /proc/acpi/button/lid/LID/state is definitely accurate now.

Still doesn't work on my HP compaq nx5000 and nc6000. Running gutsy and it's 2.6.22-14-generic kernel. Even backlight isn't turned of when closing the lid (or pressing the lid-switch).

Apparently this sounds like it could be the cause of my HP Compaq nc6320 not suspending on lid close either. I posted a comment about this under https://bugs.launchpad.net/bugs/155502

I probably should have posted here instead.

I'm not sure if it's exactly the same bug but the symptoms look similar: under Gutsy, my HP nw8000 never reports lid as being closed in /proc/acpi/button/lid/C138/state and acpid doesn't generate any events when the lid is closed, although it does generate from one up to a dozen of them (!) when it is opened.

Notice that this used to work just fine under Dapper and Feisty so this is definitely a regression. I'd be happy to provide any addition information which may be needed to narrow this down, for now I attach dmidecode output.

This bug interests also notebook HP NX6110 (linux certified: http://developer.novell.com/yes/80551.htm) on both ubuntu 7.10 and kubuntu 7.10 (although in different ways).

When I close the lid the screen is correctly turned off. Neverthless when the lid is reopened the system ignores this fact and continue to act as if the lid were still closed.
In kubuntu the screen is turned on for few seconds and then turn off again. The movement of the mouse cause a lighting followed by a sudden turning off.
In ubuntu the screen turn on correctly but programs, like "gnometris", randomly enter in paused mode.
The problem never come with earlier versions. And is really annoying in kubuntu.
(Besides it seems that the system also has problems to enter automatic suspension.)

Refer to:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/159309

Bug also in effect on HP NC6000. I have three of these notebooks. Two running Gutsy... lid state never changes therefore display doesn't shut off upon closing the lid. The other is running Feisty... lid state changes and display shuts off. Open the lid and display turns on and password prompt appears.

Works in Feisty, busted in Gutsy. Hope this is fixed soon. I like Gutsy a little better than Feisty but cannot live with this bug.

Same on HP nx7400 laptop. I'm running the latest BIOS version and it's still there. I've been running openSUSE 10.3 on this machine and it doesn't have this problem, but it did have other sorts of problems in this area, which they fixed with a kernel patch. See https://bugzilla.novell.com/show_bug.cgi?id=326814

Interesting additional detail...

If I hibernate the laptop (HP NC6000), then "wake" it back up the lid switch status now works as expected. Push the lid button and the status becomes closed and the display turns off. Release the lid button and the status becomes open and the display turns back on again. (I have my lid close action set to display off rather than suspend)

Still not ideal but since my laptop is almost always left on, until a real fix is supplied I can use this work around. Sure wish it would be fixed tho....

Does this work around spark any ideas as to the cause of the problem or better yet a solution???

-e

I have the same problem, but it won't properly shutdowr as well.

I did a upgrade to Hardy Alpha 2 (amd64) no deal. Problem is stil there.

I did an install of both ubuntu and kubuntu Gutsy on i386. No deal. Bug is still there.

I have the same problem on a HP NC6000, the state is updated *only* when the sleep button (FN+F3 is pressed and the computer awaken again).
The lid button doesn't affect the state when the computer is on...
Bios 68BDD Ver. F.14

Same problem with my HP 520 laptop, version 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux
lid state always open.

Lid state reports correctly after hibernate-resume(???)
fine in Winxp

I have same problem on my HP 520 laptop.

HP Compaq nx6310: same problem.

Under WinXP it has been working fine.
uname -r => 2.6.22-14-generic
Ubuntu Gusty Gibbon 7.10

Doesn't work for me either.

HP compaq nc6000
Ubuntu Gutsy gibbon

Additional info.

As thistleep said before;

He said that if he hibernated his nc6000 and then woke it the lid button works.
That is the case for me too. If works perfectly.

I can confirm this behavior on my Samsung Q45 (https://wiki.ubuntu.com/LaptopTestingTeam/SamsungQ45Dalia).

After boot closing the lid does nothing. After one Suspend-to-RAM and resume cycle, closing the lid works as expected.

I'll attach the dmesg after boot and after the STR-resume cycle...

I forgot to say: I'm running hardy.

Let me know if I can do something to help debugging this problem.

HP Compaq nx6310
Ubuntu Hardy Heron 8.04

Lid button still does not work.

I am experiencing the same issue under hardy on a Samsung X20 XVM 1730 V laptop. The lid button state is always reported as "closed", though.

For me, this used to work up until gutsy, I think. It is definitely a regression.

I see that the bug has been triaged. I also suffer from the bug. I'm running an up-to-date Gutsy install (uname -r = 2.6.22-14-generic).

cat /proc/acpi/button/lid/C20C/state always returns "open". Closing lid to standby works in vista, so it's not hardware failure.

Unfortunately, dmesg doesn't give any clues. I run dmesg, then close the lid, then open, and nothing new has appeared.

If I can provide more information or run some test please let me know.

I have HP 530 and Kubuntu, and lid doesn't work. I have tried Ubuntu 8.04 as live CD and it works there perfectly, also it does work from Kubuntu 8.04 live CD, BUT after a couple of seconds the display turns on.

It dos work for me now.
I'm running Xubuntu 8.04 Hardy Heron but with the gnome desktop so i guess we can say Ubuntu.

Well i have the HP Compaq nc6000 and the lid works perfekt now :)

HP nx6310: still doesn't work.

Ubundu 8.04.

I have the same problem, too...

HP 530
xubuntu 8.04
kernel: Linux version 2.6.24-19-generic (buildd@vernadsky) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Wed Jun 4 16:35:01 UTC 2008

Guys, I've bought one more HP 530 and installed Kubuntu Hardy there.

So : in LiveCD mode and after installing Kubuntu to hard disk system was reacting on laptop lid close. (But after turning off display system turned it on in a couple of seconds.)

I noticed that "vesa" driver for graphical adapter was used.

I changed driver to "intel". And then system stopped reacting on laptop lid close !

So, I think using "intel" driver can be reason for this bug. Please try to change your driver to "vesa" and check if system starts reacting correctly.

BTW, I remember that my first laptop was reacting on laptop lid close when I was using "i810" driver with "i915resolution" hacks on Feisty.

Same issue. Just as Konst also using the intel driver. With vesa it was working.

I haven't tried switching the video driver yet, but I can report that
the problem still occurs with the 2.6.26 kernel fresh from kernel.org.

Working now with hardy on HP NC6000

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

   I'm sorry, but at this moment it's not possible to get back on my
HP 530c, because I gave it to my mom, and I am abroad currently.

   Although when I get back home I'll test it ASAP, and I also think
to install testing Itrepid on my new MSI laptop (which I'm buying next
week).

   So far I haven't saw any links or etc. to download any testing
release, so I think I should install 8.04-stable and enable the
"testing" updates, right? Or, maybe, I should ask the #ubuntu-testing
at freenode?

   Anyway, thanks for keeping me intact, and thanks for Ubuntu :)

   Best regards, Latchezar Tzvetkoff

-------------------------------------

ICN.Bg с най-богатата гама от Хостинг услуги на Българския пазар
VPS сървъри - 42 лв. | Наети Сървъри - 149 лв. с ДДС
Хостинг от 2.60 лв. | Домейни (info, eu, bg) от 6.90 лв. с ДДС
  http://icn.bg/

I have a nx6110 and this issue would come and go and usually running "sudo echo 1 > /proc/acpi/video/*/DOS" would help with the issue but not always. After having the lid closed for a while the system would be almost unusable as the mouse would shake and any application would "flicker". A reboot would fix the issue (is this windows?)

I just updated to linux-image-2.6.27-3-generic, rebooted, and now the lid button doesn't work at all. I suppose that would stop the flicker though. I will continue to monitor.

Just adding a note here that this bug report will remain open against the actively developed kernel (ie the 'linux' package) but against 2.6.20 and 2.6.22 this will be closed as it does not qualify for a Stable Release Update - http://wiki.ubuntu.com/StableReleaseUpdates . Thanks.

I haven't tested the new Ubuntu kernel yet, but I still have the same issue (i.e., button state always reported as "closed") running a fresh 2.6.27.1 kernel from kernel.org.

This bug has appeared for me as a regression with 8.10. The lid switch was correctly detected in a standard installation of 8.04! The lid witch is always reported as "open".

The machine is a HP Compaq nx7400.

A

This is also a regression for me on my HP NC6000, unlike others above when the lid is closed/lid button depressed the screen stays on.

7.10 - No joy (may have started working towards the end of the release, I have a poor memory)
8.04 - Worked from the beginning of the release until the end (best release yet)
8.10 - The bug has regressed (buggiest release yet)

Please investigate.

I have recently switched from 7.04 to 8.10 (clean install).
When pressing LID button on 7.04 the screen went blank.
On 8.10 -- no reaction on LID button. I confirm the above post.
No energy saving when closing the screen :(

$ uname -r
2.6.27-7-generic

You might all be interested to know that I have found some intriguing symptoms. I was just wondering if you all had an ati card and you were all using the open ati drivers on it as opposed the fglrx drivers. if so try the vesa drivers by adding Driver "vesa" in to the Device section of your /etc/X11/xorg.conf file, reboot and watch the lid button button mysteriously start working again! I know this sounds odd but these are the empirical facts also try pressing the lid button when loading and you are on the linux kernel but not your xorg drivers and 'hey presto' the screen will blank. We may have been 'barking up the wrong tree' to coin a phrase.

same thing with intel cards - i have hp nx7400 and i950GMA on board.
Interesting thing is that, when i disconect or connect power cord or
ethernet wire the last touch of lid close button is working (i mean that
when i have closed lid before this). It might have been problem with
sending signals - something might be blocking singals form lid button.
(sory for my english ;) )

> You might all be interested to know that I have found some intriguing
> symptoms. I was just wondering if you all had an ati card and you were
> all using the open ati drivers on it as opposed the fglrx drivers. if so
> try the vesa drivers by adding Driver "vesa" in to the Device section of
> your /etc/X11/xorg.conf file, reboot and watch the lid button button
> mysteriously start working again! I know this sounds odd but these are
> the empirical facts also try pressing the lid button when loading and
> you are on the linux kernel but not your xorg drivers and 'hey presto'
> the screen will blank. We may have been 'barking up the wrong tree' to
> coin a phrase.
>
>

I also have this issue when booting into recovery mode.

So, on my machine, this has nothing to do with X.org, I think.

Hey,

I am confirm this bug on ubuntu 8.10 64 bit, my notebook is also a HP NX7400 with an intel I945GMA on board graphical chip. Anyone who knows a solution? Sometimes when my wifi is not unabled, my notebook goes into sleep when closing the lid, so I suspect that this bug has something to do with the intel wifi chipset my notebook uses.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

I have just installed the beta version of the ati driver and the lid switch started working and the screen started to go off completely and turning the back-light off.

Hi,

I am using Ubuntu 8.10 on HP NC6000 and the lid switch is always open and no change of state open or closed.

I hope it will be fixed.

Kernel 2.6.27-11

When i hibernate it and then wake it up, then the lid switch does to trigger.

Same bug here, lid always reports as "closed". Kernel 2.6.27-11. HP 530, Intel 945GME graphics.

Note: Lid button will shut screen off just fine if I boot with acpi=off. Can't suspend then though...

I have the same trouble with my laptop HP 530, both Ubuntu 8.10 and 9.04 beta!

Still broken in 9.04 on my NC6000.

acpi=off worked sometimes but sometimes just gave up and of course I lost all the goodness that came with acpi being on.
The screen turns off correctly during boot though (when the splash screen is on) and only fails when X has started.

I have the same symptoms with my NC6000 and 9.04
performing: "cat /proc/acpi/button/lid/C138/state"
with lid closed and open produces the same output, which is "state: open"

"acpi_listen" does not seem to work well in detecting the lid switch changes - almost as if it is delayed.
If I push the lid button many times, no event is seen for a long while, unless I trigger something else - such as unplug the power - then the lid button messages appear!
Nevertheless, the screen stays on.

The lid switch & backlight on/off works until gdm loads.

Booting into the recovery mode...
The backlight works, and performing the same "cat" test above shows correct "open" and "closed" states.
"acpi_listen" displays the changes immediately.

I suspect gnome-power-manager or something intercepts the lid switch signal and "drops" it or something.

as many above posters have discovered, a hibernate/resume action makes the lid switch work again.

acpi_listen shows lid switch when i press power button, just like above poster said. Lid switch event gets stuck somewhere.

Fix for this would be nice.

FWIW it still doesn't work with 9.04 on HP nw8000 neither.

Same problem here still, ACPI lid state is always open on hp dv2815nr

Still affects linux-source-2.6.28

Does anyone notice that 90% of the comments include HP laptops?

Working with the ACPI team to debug it
http://bugzilla.kernel.org/show_bug.cgi?id=13263

'acpi' is a package that provides an interface emulating an older 'apm' command; please don't assign generic ACPI bugs here.

acpi-support is also unrelated to the contents of anything under /proc/acpi.

Here is what happens with a 2.6.30 kernel from kernel.org:

After booting the system, he lid button state is reported as "closed".
After closing the lid for several seconds and opening it again, it is correctly reported as "open".
From that point on, the state is correctly reported, but with a rather long delay (c. 10 seconds).

This behavior probably hasn't changed since 2.6.26 or so.

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/89860/comments/55
This comment reminded me at my bug comment in Bug keyboard freezes on boot--sometimes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/190834/comments/13
i could get keyboard working only when pressing to ON right before Ubuntu logo appears and Loading begins
Maybe dublicate source of the problem?

I have a HP NC4400 laptop and I'm experiencing the same problem on Karmic Koala (kernel 2.6.31-3-generic). After a cold boot /proc/acpi/button/lid/C241/state always shows "open" no matter if the lid switch is activated. When the lid switch is activated the LCD backlight does turn off but does not trigger the change of ACPI state. Manual sleep from KDE power manager works as expected.

Strangely the workaround posted above corrects my problem. After a cold boot, doing a hibernate manually from KDE power manager and then waking the machine causes the lid switch to start to work correctly.

HP 530 same issue.

uname -a
Linux lucky 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux

$ ps -ef | grep acpi
root 18 2 0 19:21 ? 00:00:00 [kacpid]
root 19 2 0 19:21 ? 00:00:00 [kacpi_notify]
root 2213 1 0 19:22 ? 00:00:00 /usr/sbin/acpid -c /etc/acpi/events -s /var/run/acpid.socket
111 2543 2469 0 19:22 ? 00:00:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
hq4ever 6452 6235 0 21:52 pts/0 00:00:00 grep acpi

HP compaq NC6320. Same problem.

Also, after 'suspend to disk', the lid state is reported correctly (lshal -m and /proc/acpi/button/lid/*/state and laptop suspends as expected.

uname -a
Linux Pampus 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux

I recently upgraded to karmic 64bit from 32bit and the problem vanished. Using the stock 64bit kernel the lid switch is working properly, yet did not work in 32bit.

Upgraded to karmic 32bit. Does not work on HP Compaq nc600

As others noted before after Hibernate the lid started to work.
Unfortunately it is working till first reboot or poweroff.

HP Pavilion dv4000 -- confirming the issue on both Jaunty and Karmic.

Also, under Karmic:

suspend-->close the lid-->open the lid: laptop wakes up only to go to suspend immediately. Judging by the time stamps from the logs, the suspend sequence continues after waking up. The cycle breaks if wake up is done by pushing the power button. (this is new in Karmic for this machine)

disconnecting the AC sends the laptop into suspend (same in Jaunty and in Karmic).

trying to boot with acpi=off doesn't really fix the issue, but breaks KMS and screen compositing!

guys, please keep working on the solution.

lshal -m
and pushing lid button generates 2x times closing and opening.
Start monitoring devicelist:
-------------------------------------------------
12:12:37.511: computer_logicaldev_input_2 property button.state.value = true
12:12:37.527: computer_logicaldev_input_2 condition ButtonPressed = lid
12:12:44.040: computer_logicaldev_input_2 property button.state.value = false
12:12:44.056: computer_logicaldev_input_2 condition ButtonPressed = lid
12:12:51.135: computer_power_supply_battery_BAT0 property battery.voltage.current = 16335 (0x3fcf)

Upgraded to lucid (10.04) -- does not work.

Computer: HP compaq NC6000

Same problem on Lucid 10.04 on an HP nc6120.

Same problem with lucid and nc6000.

lshal -m
and pushing lid button does not produce any output at all (and it is not a hardware failure, checked with Windows).

Tried lucid with latest 2.6.34 kernel from mainline and the lid button worked again! Couldn't resume from hibernate though. Upgraded to mevarick beta and lid button stopped working again, sigh...

Being at it, I tried maverick beta with mainline kernel linux-image-2.6.36-999-generic_2.6.36-999.201009240945_i386.deb. This works again (nc6000)! So there's still hope...

+1 acer travelmate 5520g Linux 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:32:27 UTC 2010 x86_64 GNU/Linux

cat /proc/acpi/button/lid/LID0/state always says open

Same problem with Lucid 10.04.1 on HP 530 laptop.
Linux 2.6.32-27-generic #49-Ubuntu SMP Thu Dec 2 00:51:09 UTC 2010 x86_64 GNU/Linux

"cat /proc/acpi/button/lid/C20C/state" always says open

I noticed that after it resuming from hibernate the lid button works; if I reboot system the lid button stop working again.

I found this workaround:
https://bugzilla.redhat.com/show_bug.cgi?id=512958#c23

sudo su
echo 1 > /proc/acpi/video/C085/DOS
echo 0 > /proc/acpi/video/C085/DOS

Works for my HP compaq nc6000
Though my command is slightly different:
echo 1 > /proc/acpi/video/C0CF/DOS
echo 0 > /proc/acpi/video/C0CF/DOS

My current system is:
Ubuntu 10.04.2 LTS
2.6.32-28-generic

According to the thread mentioned in previous post the problem could be caused by the patch
"linux-2.6-acpi-video-dos.patch". Not sure if it is present in ubuntu patches.

-----------------------------------------------------
Alexei Panov 2010-03-04 17:42:54 EST

I have found a patch which breaks operation of Lid Switch on HP Mini 5101, and
possible on others HPs.
This patch is linux-2.6-acpi-video-dos.patch. If you build a kernel without
this patch lid switch perfectly works.
I suggest to test for those who have such problem, I have made a variant of a
kernel without the offending patch ftp://ftp.atisserv.ru/kernel-hp-lid/
-----------------------------------------------------

Those 2 commands work for me too on my HP NC6000 (ubuntu 10.10)

My problem is a little different. I don't know if it is related.

The state in /proc/acpi/button/lid/LID/state is ALWAYS correct.

However, after I close the lid for the first time and open it again, the gnome-power-manager always says:
"lid is closed, so we are ignoring ->NORMAL state changes"
(but the lid is open)

If I reboot or hibernate, everything goes back to the normal. It's only when I close the lid and open it again that this problem appears.

Bug still present in 11.04 . HP 530 notebook. The only thing that does not seem to work is the lid.

cat /proc/acpi/button/lid/C20C/state
state: open

State is always open, even when I press the little button that should turn off screen (on my HP the screen margins press on a little button above the keyboard when you close the lid) .

In Win 7 it works perfectly, so it's not a hardware problem.

I do not have any "/proc/acpi/video", so I can' test the above stuff.

I have a Intel 945gm express integrated video card - using the i915 video driver.

Can somebody change the status of this bug?

i confirm that bug still occurs in ubutu 11.04.
There is no /proc/acpi/video/*/DOS, it was there in beta version of 11.04 and "echo 1 >>..." workaround was working like charm.
Now we stuck with no solution...Please help. Maybe other kernel? anything - this is very irritating bug

Confirm. I have same problem with Gigabyte N601. But LID status is always "closed".
Ubuntu 11.04, x86

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

This problem still occurs in Ubuntu 11.04. What is the "series" that's not supported? The kernel version? I'm talking about 11.04 with the latest kernel--the problem still exists.

aysiu, there is new related bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/810602

Same problem on Samsung Series 9 NP9003XB running 12.04 (beta 2)

Hi, I met the same problem. I am on 11.10, upgraded from 11.04. When I close the lid, nothing happened. It affects me very much. Could you please provide the fix? Thanks!

Unsubscribe

--
Wes Garner
<email address hidden>
Mobile: 205-202-0021
Fax: 205-995-8790
On Apr 2, 2012 11:55 PM, "Robert Collins" <email address hidden> wrote:

> ** No longer affects: acpi (Ubuntu)
>
> ** No longer affects: acpi-support (Ubuntu)
>
> ** Changed in: linux-source-2.6.20 (Ubuntu)
> Assignee: Registry Administrators (registry) => (unassigned)
>
> ** Changed in: linux-source-2.6.22 (Ubuntu)
> Assignee: Registry Administrators (registry) => (unassigned)
>
> ** Changed in: linux (Ubuntu)
> Assignee: Registry Administrators (registry) => (unassigned)
>
> ** No longer affects: acpi
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/89860
>
> Title:
> /proc/acpi/button/lid/*/state always says "open"
>
> Status in “linux” package in Ubuntu:
> Won't Fix
> Status in “linux-source-2.6.20” package in Ubuntu:
> Won't Fix
> Status in “linux-source-2.6.22” package in Ubuntu:
> Won't Fix
>
> Bug description:
> My laptop is an HP Pavilion dv4000. I'm running up-to-date Feisty.
>
> Regardless of whether my laptop lid is open or closed, I always get
> this:
>
> root@peace:/etc/acpi# cat /proc/acpi/button/lid/*/state
> state: open
>
> This would explain why I can suspend the laptop using Gnome's power
> management menu, but why it doesn't do it when I close the lid. (I
> have specified under power management preferences that it's to suspend
> when I close the lid.)
>
> I know that at some level the lid switch works because when I press it
> the screen backlight turns off (although I can still faintly see that
> the display is still live).
>
> There was one hint of the issue in this email:
> http://lists.opensuse.org/opensuse-mobile/2007-02/msg00016.html
>
> Here's a Ubuntu bug that seems similar, but got rejected:
> https://launchpad.net/ubuntu/+source/kernel-package/+bug/16662
>
> My bug is different than this one:
> https://launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/34389
> because my laptop state is *always* reported as open.
>
> I've attached the output of dmesg and dmidecode.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/89860/+subscriptions
>

There is a workaround for this bug which has plagued the HP Compaq nc6120 I'm using ever since, well, forever. I was put on the track of this workaround by reading an old Advogato blog entry (http://www.advogato.org/person/mjg59/diary/62.html) where someone by the handle of 'mjg59' tells about his adventures in ACPI-land and the possible use of setpci to get around ACPI table bugs (which I consider this to be). He does not state which register he changed but I found more information elsewhere which implicated register 0xbb. As to which value to poke there I have experimented a bit as this seems to differ between systems. On the nc6120 the following command, when executed after *each* ACPI-event, restores functionality to the lid switch:

sudo setpci -s 00:1f.0 bb.b=04

I attached a tarball containing two ACPI scripts which make that this command is executed after every ACPI event. Using these scripts, my machine works as expected: the display goes black when the lid switch is pressed/the lid is closed. Opening the lid brings the display back to life. Monitoring the state of the lid switch (cat /proc/acpi/button/lid/C1E9/state on this system) shows the reported state to reflect the actual condition, where before it would stay stuck on 'closed'.

So, if you are also bitten by this bug - which has been around for *years* - you might want to try the setpci command I mentioned. If this works (directly or after changing the poked value) you might want to give these ACPI scripts a try. If you had to change the poked value to make it work, you should also change the value in the /etc/acpi/handler.sh script.

I have seen this problem with an Intel Classmate running Ubuntu 10.04 LTS (2.6.32-36 kernel) and also when using a stock kernel (2.6.32.59) which enabled me to do ACPI debugging.

It turns out that the ACPI DSDT table contains a control method _Q2A, which is repeatedly triggered by the embedded controller when automatic brightness control of the backlight is enabled (Fn+F10). This method sends repeated notifications to the kernel to adjust the brightness level, with a delay. These notifications queue up inside the kernel and cause long delays in dispatch of other notifications, such as LID events.

You can see this happening if you build a kernel with the following options:

CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_DEBUG_FUNC_TRACE=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y

and then run the following commands:

/etc/init.d/rsyslog stop
echo '0x00000004' | sudo tee /sys/module/acpi/parameters/debug_layer
echo '0x00000004' | sudo tee /sys/module/acpi/parameters/debug_level
echo -n 'file ec.c +p' | sudo tee /sys/kernel/debug/dynamic_debug/control
sudo egrep '(push query execution|ev_queue_notify_reques)' /proc/kmsg

This will show you 0x2a (_Q2A) events being constantly triggered by the embedded controller:

<7>[ 380.985859] acpi:ACPI: EC: push query execution (0x2a) on queue
<4>[ 380.996304] evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x83 (**Device Specific**)
<4>[ 380.996331] evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 83) node f70152b8
<4>[ 381.008269] evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x93 (**Device Specific**)
<4>[ 381.008295] evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 93) node f70152b8
<7>[ 381.084229] acpi:ACPI: EC: push query execution (0x2a) on queue
<4>[ 381.120283] evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x83 (**Device Specific**)
<4>[ 381.120310] evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 83) node f70152b8
<4>[ 381.132316] evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x93 (**Device Specific**)
<4>[ 381.132342] evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 93) node f70152b8

Once you press Fn+F7 to stop the automatic brightness control, the Notify queue slowly empties. LID events go to the back of the queue and so they can be executed much later when the queue is full.

It's made worse because the kernel doesn't have a driver for the Notify events (FNBT, 83 and 93) sent by the _Q2A control method, so it doesn't adjust the brightness at all, so next time the EC triggers the _Q2A control method it runs for just as long. If the kernel did adjust the brightness, the next _Q2A would do nothing.

Something similar may be happening in your case and delaying the reception of the LID events that you actually want. You might want to trace all of ACPI instead of just ec.c, since any _E or _L control method could be causing the delay, not just the embedded controller. If you see a long delay between:

<7>...

It seems a typical HP problem
For me (NC6320) I check /proc/acpi/video/C083/DOS

I fixed this in 10.04 Lucid, by putting the following lines (both needed, in this order!) into /etc/rc.local

echo 1 > /proc/acpi/video/C083/DOS
echo 0 > /proc/acpi/video/C083/DOS

However, after dist-upgrade to 12.04 this trick does not work anymore...

I'm having the same problem using Linux Mint 13 (based on Ubuntu 12.04) with a Compaq nc6000.

Lid state /proc/acpi/button/lid/C139/status is always set to "open", but if I hibernate (pm-hibernate) and wake-up, lid button works correctly.

acpi_listen shows in both cases (with and without hibernating) the lid events:
button/lid C139 00000080 00000048

The last number is increased in each event.
In each event, /etc/acpi/lid.sh is called. This script checks /proc/acpi/button/lid/*/state and acts in consecuence.

I've been running the 'fwts --interactive' test before and after hibernate.
The most significant parts:

Before:
Test 2 of 3: Test LID buttons on a single open/close.
Got 25 interrupt(s) on GPE gpe10.
Got 13 interrupt(s) on GPE gpe1D.
Got 38 interrupt(s) on GPE gpe_all.
Got 25 SCI interrupt(s).
PASSED: Test 2, Detected ACPI LID events while waiting for LID to closed.
FAILED [HIGH] NoLidState: Test 2, Could not detect lid closed state.
FAILED [HIGH] NoSCIInterrupts: Test 2, Did not detect any SCI interrupts.
FAILED [HIGH] NoGPEInterrupts: Test 2, Did not detect any GPE interrupts.
PASSED: Test 2, Detected ACPI LID events while waiting for LID to open.
PASSED: Test 2, Detected lid open state.

After:
Test 2 of 3: Test LID buttons on a single open/close.
Got 1 interrupt(s) on GPE gpe1D.
Got 1 interrupt(s) on GPE gpe_all.
Got 1 SCI interrupt(s).
PASSED: Test 2, Detected ACPI LID events while waiting for LID to closed.
PASSED: Test 2, Detected lid closed state.
Got 1 interrupt(s) on GPE gpe11.
Got 1 interrupt(s) on GPE gpe1D.
Got 2 interrupt(s) on GPE gpe_all.
Got 2 SCI interrupt(s).
PASSED: Test 2, Detected ACPI LID events while waiting for LID to open.
PASSED: Test 2, Detected lid open state.

Complete results are attached.

For those of you with a Samsung laptop showing this problem, please see this issue:

           https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/971061

in particular my last two posts.

I think a kernel patch can be made to flush the events from the embedded controller, at resume, in the same way that I do it with my C program that I attached to that issue for Samsung laptops (and maybe others with the problem). TL;DR: If the events don't get flushed (queried), the GPE of the EC is never triggered again (chicken and egg situation), my little program queries the events and "unstucks" the EC immediatly.