Lid state is incorrect (closed) after resume with lid open

Bug #34389 reported by Ben on 2006-03-11
92
This bug affects 3 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Unassigned

Bug Description

On latest Dapper, Dell Inspiron 700m:

ben@catbee:~$ cat /proc/acpi/button/lid/LID0/state
state: open

I close the lid, wait for the computer to suspend. Then I open the lid, the computer resumes.

ben@catbee:~$ cat /proc/acpi/button/lid/LID0/state
state: closed

This is a problem, for example, if i unplug the compute from AC, it triggers a "power" event, which seeing the lid is "closed" causes my computer to go to sleep, which is annoying.

I can make the lid state go back to "open" by quickly closing and opening the lid, without letting the computer sleep. If the lid is in the "closed" state, it seems to persist across reboots.

Matt Zimmerman (mdz) wrote :

Please attach the output from "dmesg" and "sudo dmidecode"

Changed in linux-source-2.6.15:
status: Unconfirmed → Needs Info
Ben (midfield) wrote : dmesg

dmesg output as requested.

Ben (midfield) wrote : dmidecode.out

dmidecode output as requested.

i've attached the dmesg and dimedecode as you've requested.

thanks,
Ben

On 4/5/06, Matt Zimmerman <email address hidden> wrote:
> Please attach the output from "dmesg" and "sudo dmidecode"
>
> ** Changed in: acpi (Ubuntu)
> Sourcepackagename: acpi => linux-source-2.6.15
> Binarypackagename: acpi => None
>
> ** Changed in: linux-source-2.6.15 (Ubuntu)
> Status: Unconfirmed => Needs Info
> --
> Lid state is incorrect
> https://launchpad.net/malone/bugs/34389
>

I'm confirming this because my laptop appears to have the same issue. I will attach my dmidecode and dmesg as requested also. I suspect this may be related to Bug #37626 which I will also mark as confirmed.

My laptop is an Averatec 4155 and I'm running dapper.

Changed in linux-source-2.6.15:
status: Needs Info → Confirmed

output from sudo dmidecode

output from dmesg.

Disregard comment about Bug #37626, I hadn't read that one carefully enough, this isn't related.

Paul Sladen (sladen) wrote :

I think this is probably worked around by the fix for bug #21576.

Can you retest with the laptop 'hal' installed?

i don't know if i have laptop "hal" installed. how do i check? i do
have "hal" installed, and i just did a fresh apt-get dist-upgrade
which caught a new version.

i still seem to get the same problem. cat
/proc/acpi/button/lid/LID0/state gives open, close lid, wait for
suspend, open lid, cat, get closed. sometimes if i tap the lid button
i can get it to go open, though that is not changed from previous
versions. what has changed is the screensaver comes up with a
password, which wasn't working before.

thanks, Ben

On 5/9/06, Paul Sladen <email address hidden> wrote:
> I think this is probably worked around by the fix for bug #21576.
>
> Can you retest with the laptop 'hal' installed?
>
> --
> Lid state is incorrect
> https://launchpad.net/bugs/34389
>

Can you paste the output from:

  dpkg -l | awk '/hal/{print$2,$3}'

hunger (hunger) wrote :

Mine is:

> dpkg -l | awk '/hal/{print$2,$3}' ~
hal 0.5.7-1ubuntu17
hal-device-manager 0.5.7-1ubuntu17
hashalot 0.3-3
libhal-storage1 0.5.7-1ubuntu17
libhal1 0.5.7-1ubuntu17

But I still think I got a different bug (#43519), even though someone disagrees and marked mine a duplicate of this one. I could not "unduplicate" the bug, so I opened a new one (#45546) about my issue (laptop suspends fine, resumes fine and then does a shutdown). I am using "pmi action suspend", so my lid is always open...

Paul Sladen (sladen) wrote :

hunger: I'm slightly confused. BTW, you can unduplicate a bug by clicking "Mark as duplicate" and then deleting the number from the box and then saving it.

Please could you duplicate the one that you think is a bug and then we'll have a look at it again.

$ dpkg -l |awk '/hal/{print$2,$3}'
hal 0.5.7-1ubuntu17
hal-device-manager 0.5.7-1ubuntu17
libhal-storage1 0.5.7-1ubuntu17
libhal1 0.5.7-1ubuntu17

Ben (midfield) wrote :

ben@catbee:~$ dpkg -l | awk '/hal/{print$2,$3}'
hal 0.5.7-1ubuntu17
hal-device-manager 0.5.7-1ubuntu17
libhal-storage1 0.5.7-1ubuntu17
libhal1 0.5.7-1ubuntu17
ben@catbee:~$ cat /proc/acpi/button/lid/LID0/state
state: closed
ben@catbee:~$

Note it says my lid is closed, which would make it rather hard to type this message!

Paul Sladen (sladen) wrote :

Mmm. Buggy ACPI then.

Might be able to do some sort of hack at the gnome-power-manager level that says that if there is keyboard activity, force the LID open; but this would probably introduce as many extra complexities as it would solve - for instance, what happens when the machine is closed with extra VGA, keyboard and mouse connected.

Do you mind reporting this to the ACPI powers-that-be? I'm not sure
where to look...

B

On 5/19/06, Paul Sladen <email address hidden> wrote:
> Mmm. Buggy ACPI then.
>
> Might be able to do some sort of hack at the gnome-power-manager level
> that says that if there is keyboard activity, force the LID open; but
> this would probably introduce as many extra complexities as it would
> solve - for instance, what happens when the machine is closed with extra
> VGA, keyboard and mouse connected.
>
> --
> Lid state is incorrect
> https://launchpad.net/bugs/34389
>

It may be that our ACPI is just buggy, but I have my doubts. I haven't tested in Windows but I'll bet it works fine there. On the other hand I think there's also a bug in g-p-m here:

It would be better if it reacted to the state change rather than the state. Paul mentions external keyboards and mice, well this is important because I may have an external keyboard, mouse, and monitor and if I do I probably have the lid closed. If I lose power I don't want the machine to suspend under that circumstance. The correct behavior would be to suspend on a change from lid open to lid closed, not to check the state of the lid on a change from plugged to unplugged.

I agree with this assessment.

As a data point, my laptop (a dell 700m) worked fine with windows XP.

I'm also having a problem where closing the lid sometimes doesn't
suspend. Also closing the lid while in the process of hibernating
pauses the hibernation -- this is a real problem, the standard usage
pattern is to click "hibernate", close the lid, put it in the laptop
bag. If I do this now the computer will overheat and/or run out of
batteries fast. I'm thinking I should file another bug report...

On 5/19/06, Andrew Jorgensen <email address hidden> wrote:
> It may be that our ACPI is just buggy, but I have my doubts. I haven't
> tested in Windows but I'll bet it works fine there. On the other hand I
> think there's also a bug in g-p-m here:
>
> It would be better if it reacted to the state change rather than the
> state. Paul mentions external keyboards and mice, well this is
> important because I may have an external keyboard, mouse, and monitor
> and if I do I probably have the lid closed. If I lose power I don't
> want the machine to suspend under that circumstance. The correct
> behavior would be to suspend on a change from lid open to lid closed,
> not to check the state of the lid on a change from plugged to unplugged.
>
> --
> Lid state is incorrect
> https://launchpad.net/bugs/34389
>

I have similar problems (bug #43391) and as I wrote there, it is possible to go round this problem by removing /etc/acpi/lid.sh and then commanding: sudo ln -s /etc/acpi/sleepbtn.sh /etc/acpi/lid.sh.

This has the effect that when the lid is closed the machine runs sleepbtn.sh and effectively puts it in sleep state =)

Of course this does not solve the problem, but makes it easier to live with it...

hardyn (arlenn) wrote :

same here... although the lid switch does not work at all in gutsy... kernel 2.6.22. the notebook does suspend just fine using the fn+ key combination.
the display does blank... so i would assume the switch is being polled or interrupted correctly, but something is happening when it comes to the suspending.

Lets keep this bug report just for the originally report Inspiron 700m.

hardyn: can you open a new bug report please, specially mentioning the model of laptop you have in the title.

Bill Egert (begert) wrote :

I am having the same problem with my Averatec laptop. I will open a new bug report with my model in the title.

I confirm the bug on my HP-Compaq nc6120 running Kubuntu Hardy Beta (kernel v 2.6.24-12). At the suggestion of Paul Sladen, I have opened a specific bug with the number #206511.

Looks like this is related to bug #140679. Also, check out bug report #157691 for a possible explanation and, more importantly, a workaround.

The solution proposed in #157691 works for me. The lid button works perfectly now! For the details, go to
http://ubuntuforums.org/showthread.php?t=587390&page=3

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this linux-source-2.6.15 kernel bug to the new "linux" package. We appreciate your patience and understanding as we make this transition. Also, if you would be interested in testing the upcoming Intrepid Ibex 8.10 release, it is available at http://www.ubuntu.com/testing . Please let us know your results. Thanks!

I can still make this happen with the latest Ibex kernel (2.6.26-5-generic).

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.

On Thu, Aug 28, 2008 at 12:33 PM, Leann Ogasawara <email address hidden> wrote:
> 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:

Tested with 2.6.27-2. Bug still present.

--
Will Dyson

Changed in linux:
assignee: nobody → ubuntu-kernel-team
status: Confirmed → Triaged

I can also confirm this bug is still present with 2.6.27-7-generic kernel in Ubuntu 8.10 on my Toshiba A100. I did the following steps to test:

1) Go to "System->Preferences->Power Management" and set "Do Nothing" for the "When laptop lid is closed" setting on AC Power and on Battery power.

2) Open a terminal window and type the following to monitor the lid state:

      while true
      do
          cat /proc/acpi/button/lid/LID/state
          sleep 1
      done

3) Close and open the lid to see the state changes fine when machine does not suspend.

4) Reset the power management settings to suspend on lid close and the problem of the lid state being reported as closed when waking from suspension is back.

When I close the lid the second time the system will not suspend since the lid state is reported as closed. But upon opening the lid after closing it the second time the lid state is correctly reported as open. So, the machine will suspend properly on every second closing of the lid. I am surprised this is not fixed for this long. Are we reporting this problem to the wrong place?

wook (adam-brenyo) wrote :

Hi,

With my Toshiba A100 I'm experienced the same things as Sudarsha. I think the problem's root probably somewhere in the kernel, because the proc/acpi/button/lid did not refreshed with this bios after a sleep-resume cycle.

I'm realized that the acpid have been able to handle the lid state change, so I write a little patch, and a script for the pm-utils package.

This is a workaround, not solves the problem, but the machine reliably sleep when the lid closed.

the file in /etc/pm/sleep.d is necessary beacause if the hal lid state remains true, and the power state changed (ac disconnected) machine will go to sleep.

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.

Ok, I've finally come up with a pretty good work around for this. First, go to this website: http://www.linux.com/articles/54610 and follow the instructions to create your own sleep file and command to launch it when the lid is closed. You don't need to bother with the commands for hibernating when the power button is pushed. One thing I did differently though than the web site was when you write this line:

event=button[ /]lid.*

I did it this way instead:

event=button[/]lid.*

Once you restart, the computer should reliably suspend when you close the lid. You can leave it like this if you like, but the gnome-power-management wont control anything.

If you want to get gnome-power-manager working again, log in as root and go to /etc/acpi and pull the event and actions folder to the desktop. Now open up synaptic and search for acpi. Go through and select each result and check it for reinstall. Then apply the changes and your /ect/acpi directory should be back to it's original defaults. Now drag the actions and events folders that you put on the desktop into /etc/acpi and overwrite when prompted. Restart the computer and then open up power management. Select action when lid is closed for a/c and battery to “do nothing.” This is because our new commands will handle that, but every other aspect of gnome-power-management still works normally.

The only problems with this workaround on my Inspiron 700M is that it does not prompt for a password when you resume from suspend. This is actually preferable for me, but I'm sure someone can figure a way to add that feature in. Also, lid state always returns as “closed” now instead of going back and forth. I have not found anything yet, however, that is impacted by this.

TJ (tj) wrote :

If you're still experiencing this issue with Hardy, Intrepid or Jaunty please report/attach the following after enabling kernel debug logging.

To enable kernel debug enter the GRUB menu at start-up by pressing ESCape. Highlight the kernel to boot, press "E" to edit it. Highlight the "kernel" line and press "E" to edit it. At the end of the line remove "quiet splash" and replace with " debug". Press Enter, then press "B" to boot with the changed parameters.

Do a start-up, suspend, resume cycle. Attach /var/log/kern.log to a comment containing these reports:

uname -a
lsb_release -a

Zhang Rui (rui-zhang) wrote :

The incorrect Lid state problem seems like a Linux/ACPI bug.
it would be great if you guys can file a new bug report at
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
as this is the place we use to track ACPI kernel bugs.
please attach the acpidump output by using the latest pmtools at
http://www.lesswatts.org/projects/acpi/utilities.php

BTW, don't forget to add the model name of your laptop.

TJ (tj) wrote :

Rui, it is best for the bugs to be reported here on the Ubuntu bug-tracker in the first instance since they may be related to Ubuntu Sauce or other patches to the kernel, or may even be some by-product of user-space tools and configuration.

If after we've analysed a report we can be sure there is an upstream issue that is still current we'll open a report on the relevant bug-tracker (or find an existing report) and link it from here.

I don't want to be chasing back and forth from Launchpad to kernel.org trying to analyse an issue.

Changed in linux:
assignee: nobody → intuitivenipple
status: Triaged → In Progress
Zhang Rui (rui-zhang) wrote :

okay.
I got some similar problems (wrong lid state) before, and have root caused that they're BIOS problems and some of them can be fixed by overriding the DSDT.

so it would be great if anyone with this problem can attach the acpidump here so that I can see if this is a duplicate.

Joonas Saarinen (jza) wrote :

Here goes.

Earlier I posted some more details in bug #44825 which was marked as a duplicate of this one.

Joonas Saarinen (jza) wrote :

By the way, the lid state is set correctly if using the (I believe now obsolete) /etc/acpi scripts.

Zhang Rui (rui-zhang) wrote :

joonas,

could you please try this customized DSDT to see if it helps?

> the lid state is set correctly if using the (I believe now obsolete) /etc/acpi scripts.
what do you mean?
the problem only exists when acpid is stopped?

Joonas Saarinen (jza) wrote :

Thanks. It seems that requires a kernel recompile, I will look on that soon when I have more time.

Never mind the talk about /etc/acpi, I rechecked and it seems the problem is present no matter what script is used to suspend.

Joonas Saarinen (jza) wrote :

Zhang: Actually, could I have that as an .aml file?

Zhang Rui (rui-zhang) wrote :

DSDT.aml attached.

Joonas Saarinen (jza) wrote :

Hmm, the patched DSDT seems to flood ACPI lid events all the time.

Zhang Rui (rui-zhang) wrote :

yes, you are right, now how about this DSDT.

Joonas Saarinen (jza) wrote :

The lid triggers events normally now, but /proc/acpi/button/lid/LID0/state prints always "state: unsupported".

Joonas Saarinen (jza) wrote :

Note that I always wake up the machine using the power button, not lid. I don't know if this makes a difference though...

Zhang Rui (rui-zhang) wrote :

please make sure that CONFIG_ACPI_DEBUG is set in your kernel config file,
and then try this test,
1. dmesg -c
2. echo 0xffffffff > /sys/module/acpi/parameters/trace_debug_layer
3. echo 0xffffffff > /sys/module/acpi/parameters/trace_debug_level
4. echo _LID > /sys/module/acpi/parameters/trace_method_name
5. echo 1 > /sys/module/acpi/parameters/trace_state
6. cat /proc/acpi/button/lid/LID0/state
7. attach the dmesg output here.

Joonas Saarinen (jza) wrote :

Ok. I compiled 2.6.24.6 with CONFIG_ACPI_DEBUG and CONFIG_ACPI_DEBUG_FUNC_TRACE, although /sys/module/acpi/parameters contains only "acpica_version", "debug_layer" and "debug_level". I did the test anyway.

Zhang Rui (rui-zhang) wrote :

please try a new kernel, say 2.6.29.
I'm not sure if the ACPI trace stuff is introduced in 2.6.24 or not, but try a vanilla 2.6.29 kernel would be a better choice here.

Zhang Rui (rui-zhang) wrote :

BTW, please clear acpi debug_level and debug_layer before the test.
i.e. additional to the previous test, please
0.5. echo 0 > /sys/module/acpi/parameters/debug_layer
0.6. echo 0 > /sys/module/acpi/parameters/debug_level

Joonas Saarinen (jza) wrote :

Retested with 2.6.28 (Ubuntu source), dmesg attached. All the debug parameters are now present, yet the log looks pretty much the same as before...

I can also test with an even more recent vanilla kernel if needed. For that I will need a .hex file again, because I couldn't see any initrd aml loading mechanism there. (Tried aml->hex conversion myself using iasl but just got a bunch of errors.)

Zhang Rui (rui-zhang) wrote :

hah, I see what the problem is.
this customized DSDT should fix the problem for you, please give it a try.

Joonas Saarinen (jza) wrote :

Wow, it really works now. Great job. :)

Zhang Rui (rui-zhang) wrote :

So, this is clearly a BIOS problem to me and we can not fix/workaround it in kernel.
And I think users need to use the customized DSDT as a workaround.
IMO, the bug can be closed.

thanks,
rui

zhangx (zhangxmail) wrote :

I can also confirm this bug is still present with 2.6.31.13-386 kernel in Ubuntu 9.10rc on my Dell Inspiron 700m.

Davidiam (hectorjerezano) wrote :

Rui Could you please fix my DSDT vaio vpcw120al, it detects de Lid state correct , open and close but at boot it always state close so if I unplug power cord it goes to sleep unless y intensionally close and open the lid before I unplug the cord then it works correctly , so apparently at boot does not refresh the state.
Also when it goes to sleep it takes accople of seconds extras to finish living the screen on and fan on for ~30 seg.

Zhang Rui (rui-zhang) wrote :

Davidiam,
please try the custom DSDT attached.

Davidiam (hectorjerezano) wrote :

Thank you! it is working now!

Changed in linux (Ubuntu):
assignee: TJ (intuitivenipple) → nobody
status: In Progress → Triaged
Brad Figg (brad-figg) wrote :

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 supported series, please file a new bug.

Changed in linux (Ubuntu):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers