upower --dump often reports that laptop lid is closed when it's open. This can have bad consequences like Bug 694703, but may also be one of the causes of incidental suspends. This bug is triggered by opening the laptop lid when laptop is suspended and connected to AC power. The laptop resumes but doesn't change the upower lid state from 'closed' to 'open'. upower-0.9.10-1.fc15.i686 kernel: 2.6.38.8-32.fc15.i686.PAE How reproducible: Always. Steps to Reproduce: With laptop on AC power without external screen: 1. Boot the computer and optionally login from another computer with SSH 2. Close the lid and wait 3. Open the lid and wait 4. Close the lid and wait 5. Open the lid and wait Test with 'upower --dump | grep lid-is-closed' after each step. You may need to reconnect SSH when it freezes. Actual results: after 1) lid-is-closed: no after 2) computer is suspended after 3) lid-is-closed: yes (!) after 4) lid-is-closed: yes after 5) lid-is-closed: no after 6) computer is suspended after 7) lid-is-closed: yes In fact, every four steps repeat periodically. This means you have to close the lid twice to suspend the computer instead of once. Please note that there are three states: open, closed and suspended Expected results: after 1) lid-is-closed: no after 2) computer is suspended after 3) lid-is-closed: no after 4) computer is suspended Every two steps should repeat periodically and there should be only two states: open (we're working) closed (and suspended) Other states should not occur at all by only opening and closing the lid. (open+suspended should occur only when you select suspend manually or if you open the lid without AC power, closed+running should be only with external screen or docking station).
Bug 609081 may also describe one of the symptops of this bug.
If anyone could help me with more debugging and fixing the bug, feel free to contact me through pavlix at pavlix.net. I'd be happy to have this bug fixed.
I am having this issue with suspend working as well. upower --dump report in case needed. Device: /org/freedesktop/UPower/devices/line_power_ADP0 native-path: /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/ADP0 power supply: yes updated: Thu Oct 6 18:43:26 2011 (22160 seconds ago) has history: no has statistics: no line-power online: yes Device: /org/freedesktop/UPower/devices/battery_BAT0 native-path: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0 model: PA3535U-1BRS serial: 00B4 power supply: yes updated: Fri Oct 7 00:52:34 2011 (12 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: fully-charged energy: 81.9265 Wh energy-empty: 0 Wh energy-full: 81.9265 Wh energy-full-design: 141.864 Wh energy-rate: 0 W voltage: 23.644 V percentage: 100% capacity: 57.7333% technology: lithium-ion Daemon: daemon-version: 0.9.12 can-suspend: yes can-hibernate yes on-battery: no on-low-battery: no lid-is-closed: no lid-is-present: yes is-docked: no
If the lid state is incorrect (hardware bug, kernel bug, whatever) you can change IgnoreLid=true in /etc/UPower/UPower.conf to have the lid state ignored.
„If the lid state is incorrect (hardware bug, kernel bug, whatever) you can change IgnoreLid=true in /etc/UPower/UPower.conf to have the lid state ignored.“ Which is a good workaround for the random suspends (and thanks for it), but if I just disable every broken feature, I may just easily end up with something I had many years ago.
(In reply to comment #5) > ...I may just easily end up with something I had many years ago. Is the hardware known good? Have you tried with windows to rule out a bad lid switch?
The lid switch works well in Fedora 15, AFAIK there's no need to test with windows (and I don't have any windows live usb to test). The state is wrong *only* after suspend. It might be enough to force the drivers to re-query the lid state after every suspend-resume cycle.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping