Lid state is incorrect (closed) after resume with lid open
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Won't Fix
|
Medium
|
Unassigned |
Bug Description
On latest Dapper, Dell Inspiron 700m:
ben@catbee:~$ cat /proc/acpi/
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/
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 : | #1 |
Changed in linux-source-2.6.15: | |
status: | Unconfirmed → Needs Info |
Ben (midfield) wrote : dmesg | #2 |
Ben (midfield) wrote : dmidecode.out | #3 |
Ben (midfield) wrote : Re: [Bug 34389] Re: Lid state is incorrect | #4 |
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:/
>
Andrew Jorgensen (ajorg) wrote : Re: Lid state is incorrect | #5 |
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 |
Andrew Jorgensen (ajorg) wrote : dmidecode | #6 |
Andrew Jorgensen (ajorg) wrote : dmesg | #7 |
Andrew Jorgensen (ajorg) wrote : Re: Lid state is incorrect | #8 |
Disregard comment about Bug #37626, I hadn't read that one carefully enough, this isn't related.
Paul Sladen (sladen) wrote : | #9 |
I think this is probably worked around by the fix for bug #21576.
Can you retest with the laptop 'hal' installed?
Ben (midfield) wrote : Re: [Bug 34389] Re: Lid state is incorrect | #10 |
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/
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:/
>
Paul Sladen (sladen) wrote : Re: Lid state is incorrect | #11 |
Can you paste the output from:
dpkg -l | awk '/hal/{print$2,$3}'
hunger (hunger) wrote : | #12 |
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 : | #13 |
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.
Andrew Jorgensen (ajorg) wrote : | #14 |
$ 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 : | #15 |
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/
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 : | #16 |
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.
Ben (midfield) wrote : Re: [Bug 34389] Re: Lid state is incorrect | #17 |
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:/
>
Andrew Jorgensen (ajorg) wrote : Re: Lid state is incorrect | #18 |
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.
Ben (midfield) wrote : Re: [Bug 34389] Re: Lid state is incorrect | #19 |
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:/
>
Mikko Saarinen (mikk0) wrote : Re: Lid state is incorrect | #20 |
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/
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 : | #21 |
- dmesg dmidecode files Edit (40.0 KiB, application/x-tar)
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.
Paul Sladen (sladen) wrote : Re: Lid state is incorrect on Dell Inspiron 700m | #22 |
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 : | #23 |
I am having the same problem with my Averatec laptop. I will open a new bug report with my model in the title.
Gerhard Kremer (gerhardusm2002) wrote : | #24 |
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.
Gerhard Kremer (gerhardusm2002) wrote : | #25 |
The solution proposed in #157691 works for me. The lid button works perfectly now! For the details, go to
http://
Launchpad Janitor (janitor) wrote : This bug is now reported against the 'linux' package | #26 |
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://
WillDyson (will-dyson) wrote : Re: Lid state is incorrect on Dell Inspiron 700m | #27 |
I can still make this happen with the latest Ibex kernel (2.6.26-5-generic).
Leann Ogasawara (leannogasawara) wrote : | #28 |
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-
--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://
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.
WillDyson (will-dyson) wrote : Re: [Bug 34389] Re: Lid state is incorrect on Dell Inspiron 700m | #29 |
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 |
sudarsha (sudarsha) wrote : Re: Lid state is incorrect on Dell Inspiron 700m | #30 |
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-
2) Open a terminal window and type the following to monitor the lid state:
while true
do
cat /proc/acpi/
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 : | #31 |
- acpid lid state workaround Edit (1.1 KiB, application/octet-stream)
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/
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.
Launchpad Janitor (janitor) wrote : Kernel team bugs | #32 |
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:/
johnp51d (john-mcalister) wrote : Re: Lid state is incorrect on Dell Inspiron 700m | #33 |
Ok, I've finally come up with a pretty good work around for this. First, go to this website: http://
event=button[ /]lid.*
I did it this way instead:
event=button[
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-
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-
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.
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 : | #35 |
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://
as this is the place we use to track ACPI kernel bugs.
please attach the acpidump output by using the latest pmtools at
http://
BTW, don't forget to add the model name of your laptop.
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 : | #37 |
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 : | #38 |
- acpidump.txt Edit (186.2 KiB, text/plain)
Here goes.
Earlier I posted some more details in bug #44825 which was marked as a duplicate of this one.
Joonas Saarinen (jza) wrote : | #39 |
By the way, the lid state is set correctly if using the (I believe now obsolete) /etc/acpi scripts.
Zhang Rui (rui-zhang) wrote : | #40 |
- customized DSDT -- always refresh the lid state in _LID Edit (318.7 KiB, text/plain)
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 : | #41 |
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 : | #42 |
Zhang: Actually, could I have that as an .aml file?
Zhang Rui (rui-zhang) wrote : | #43 |
Joonas Saarinen (jza) wrote : | #44 |
Hmm, the patched DSDT seems to flood ACPI lid events all the time.
Zhang Rui (rui-zhang) wrote : | #45 |
Joonas Saarinen (jza) wrote : | #46 |
The lid triggers events normally now, but /proc/acpi/
Joonas Saarinen (jza) wrote : | #47 |
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 : | #48 |
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/
3. echo 0xffffffff > /sys/module/
4. echo _LID > /sys/module/
5. echo 1 > /sys/module/
6. cat /proc/acpi/
7. attach the dmesg output here.
Joonas Saarinen (jza) wrote : | #49 |
- dmesg-lid.txt Edit (17.4 KiB, text/plain)
Ok. I compiled 2.6.24.6 with CONFIG_ACPI_DEBUG and CONFIG_
Zhang Rui (rui-zhang) wrote : | #50 |
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 : | #51 |
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/
0.6. echo 0 > /sys/module/
Joonas Saarinen (jza) wrote : | #52 |
- dmesg-lid2.txt Edit (13.4 KiB, text/plain)
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 : | #53 |
- customized DSDT Edit (34.0 KiB, application/octet-stream)
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 : | #54 |
Wow, it really works now. Great job. :)
Zhang Rui (rui-zhang) wrote : | #55 |
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 : | #56 |
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 : | #57 |
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 : | #58 |
- custom DSDT: Fix a problem that LIDS is always set to 1 during initialization. Edit (182.1 KiB, text/plain)
Davidiam,
please try the custom DSDT attached.
Davidiam (hectorjerezano) wrote : | #59 |
Thank you! it is working now!
Changed in linux (Ubuntu): | |
assignee: | TJ (intuitivenipple) → nobody |
status: | In Progress → Triaged |
Brad Figg (brad-figg) wrote : | #60 |
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 |
Please attach the output from "dmesg" and "sudo dmidecode"