GNOME Bugzilla – Bug 607035
laptop does not suspend when lid is closed
Last modified: 2012-07-14 00:12:02 UTC
Gnome-power-manager is set to suspend on lid close, but when the lid is closed the system does not suspend. /proc/acpi/button/lid/C1C4/state shows correct state in open and closed case. See Ubuntu bug at <https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/376793> for more info.
Original reporter in Ubuntu bug was using an HP 2140, but others could reproduce the issue with different laptops.
Nevermind, all reporters for this specific bug are using the HP 2140.
(In reply to comment #0) > Gnome-power-manager is set to suspend on lid close, but when the lid is closed > the system does not suspend. > > /proc/acpi/button/lid/C1C4/state shows correct state in open and closed case. Nothing uses /proc/acpi anymore. The more important metric is what DeviceKit-power thinks the state is. Try running "devkit-power --dump" when the lid is closed and open and see if the lid properties change. It might also be worth trying DeviceKit-power from git master as a debian specific fix was merged recently.
Created attachment 151691 [details] devkit-power --dump (closed)
Created attachment 151692 [details] devkit-power --dump (open)
OK, I've attached the dumps from the Ubuntu reporter. Note that the lid status is correct in both. See the Ubuntu report for more information.
Hello all, This bug has been reported in Red Hat too. They claim it is a kernel bug, fixed in kernel 2.6.32 https://bugzilla.redhat.com/show_bug.cgi?id=512958 "kynde 2009-12-08 04:12:25 EST This originates to kernel acpi drivers. The button.c uses what it gets from acpi_device_bid for the directory name aswell as for the Lid Switch [%s] printk. The acpi_device_bid is, if I understood correcrly, filled with what it gets from drivers/acpi/scan.c: static void acpi_device_get_busid(struct acpi_device *device) which in turn defaults to calling acpi_get_name from acpica/nsxfname.c. Now, why that returns C1D0 rather than LID is beyond me. And about missing events, I think it has to do with acpi_lid_send_state -> acpi_evaluate_integer -> acpi_evaluate_object and all the "magic" it does there with names Someone with more knowledge of kernel acpi internals might want to take a look at this. I'm willing try any patches or produce debugs etc. I'll compile the kernel with CONFIG_ACPI_DEBUG later tonight when I have access to said laptop again (it's my wife's, you see) and check if that shows anything relevant. Comment 6 kynde 2009-12-09 17:09:55 EST I've just finished testing with the latest fedora 12 kernel (2.6.31.6-162) and the problem persist, _but_ I compiled the stock 2.6.32 with the config from said fedora kernel and low and behold, the lid acpi signaling works. acpi_listen shows the lid events and system suspended when I configured it to from power management. This was about the HP mini 5101 and I have no idea what the situation is with hp mini 2140 what this bug is about. Hopefully those acpi changes make it to the fedora kernel soon. I glanced briefly but didn't spot them in 2.6.31.y yet either."
The Ubuntu bug has been shown to be a kernel issue, so this issue can be closed as far as I'm concerned.
The correction described in https://bugzilla.redhat.com/show_bug.cgi?id=512958 seems to be only for the cases where /proc/acpi/button/lid/LID0/state does NOT show the correct state. Though, there are cases where /proc/acpi/button/lid/LID0/state shows the correct state, but the gnome-power-manager does not recognizes the state changes. In those cases, the workaround suggested in that bug report does not solve the problem. And, in the verbose mode, the gnome-power-manager shows: "lid is closed, so we are ignoring ->NORMAL state changes" (but the lid is open) Is this a different problem? Is there any solution? Thank you!
(In reply to comment #3) > (In reply to comment #0) > > Gnome-power-manager is set to suspend on lid close, but when the lid is closed > > the system does not suspend. > > > > /proc/acpi/button/lid/C1C4/state shows correct state in open and closed case. > > Nothing uses /proc/acpi anymore. The more important metric is what > DeviceKit-power thinks the state is. > > Try running "devkit-power --dump" when the lid is closed and open and see if > the lid properties change. It might also be worth trying DeviceKit-power from > git master as a debian specific fix was merged recently. In my case this is exactly the problem. Using upower --dump it says that the lid is closed when it is open: Daemon: daemon-version: 0.9.5 can-suspend: yes can-hibernate yes on-battery: yes on-low-battery: no lid-is-closed: yes lid-is-present: yes That's why the output of gnome-power-manager shows: "lid is closed, so we are ignoring ->NORMAL state changes" And that's also why I only experience this problem with gnome-power-manager. Xfce-power-manager works correctly as it uses hal. However, when I boot the laptop, everything works properly. Only after I close the lid for this first, the problem begins. I tested this, in the same laptop, in Ubuntu with gpm 2.32 and in Debian with gpm 2.30. The laptop is an HP dv 1359 with 5 years old. Is there any workaround or any kind of solution? Is this the same problem or should I open a different report? Thank you!
Hi, This and the downstream bugs have been reported a *very* long time ago, and I'm unable to reproduce this with GNOME 3.4 on Fedora 17 on a Thinkpad X220 (or any other laptop I've used or encountered in the past years). Reopen this bug if the problem still occurs with a newer version of GNOME, but it is highly probable that this is a kernel bug rather than gnome power manager.