Description of problem: Laptop suspends several seconds after de-suspending. Version-Release number of selected component (if applicable): pm-utils-015-1 How reproducible: alwasy Steps to Reproduce: 1. Set powermanagement preferences to always suspend when lid closed. 2. close lid while on ac. Unplug ac 3. open lid Actual results: Laptop wakes up and then suspends again after 5 to 10 seconds Expected results: Laptop should wake up and not suspend again Additional info: On suspending when laptop lid is closed a message is logged "gnome-power-manager: Suspending computer because the lid has been closed on ac power" After opening the lid computer desuspends and then suspends again with the message "gnome-power-manager: Suspending computer because the lid has been closed, and the ac adapter removed" even though the lid is now open.
Other wierd an undesired behaviour today (at a conference using my laptop): removing the power while lid is open, laptop goes to sleep and logs the message: Suspending computer because the lid has been closed, and the ac adapter removed I can't recall the sequence of events that has put it in this state (computer has been put to sleep and woken many times since last reboot), but has done it twice today.
See http://bugzilla.gnome.org/show_bug.cgi?id=334220 for more information... Looks like the same bug to me. I think the reason that this is not working is because hal does not send events notifications for events that happened during sleep... I ran a few tests with lshal --monitor while closing and opening my laptop lid. Having gnome-power-manager set to do nothing on lid close, i get: acpi_LID property button.state.value = true acpi_LID condition ButtonPressed = lid acpi_LID property button.state.value = false acpi_LID condition ButtonPressed = lid Having gnome-power-manager set to suspend on lid close, i get: acpi_LID property button.state.value = true acpi_LID condition ButtonPressed = lid Also, running "lshal -l -u /org/freedesktop/Hal/devices/acpi_LID" after resume gives me this : udi = '/org/freedesktop/Hal/devices/acpi_LID' info.udi = '/org/freedesktop/Hal/devices/acpi_LID' (string) linux.hotplug_type = 4 (0x4) (int) button.has_state = true (bool) button.state.value = false (bool) info.capabilities = {'button'} (string list) info.category = 'button' (string) info.product = 'Lid Switch' (string) button.type = 'lid' (string) info.parent = '/org/freedesktop/Hal/devices/computer' (string) linux.acpi_type = 10 (0xa) (int) linux.acpi_path = '/proc/acpi/button/lid/LID' (string) Restarting haldaemon and retrying gives me: udi = '/org/freedesktop/Hal/devices/acpi_LID' info.udi = '/org/freedesktop/Hal/devices/acpi_LID' (string) linux.hotplug_type = 4 (0x4) (int) button.has_state = true (bool) button.state.value = true (bool) info.capabilities = {'button'} (string list) info.category = 'button' (string) info.product = 'Lid Switch' (string) button.type = 'lid' (string) info.parent = '/org/freedesktop/Hal/devices/computer' (string) linux.acpi_type = 10 (0xa) (int) linux.acpi_path = '/proc/acpi/button/lid/LID' (string) So it seems pretty clear to me that the hal simply fails to update its lid status properly... This is seriously annoying, so lets try to get this one fixed! I haven't tried CVS hal, but I tried the updated scripts that adds somethig like this to the suspend/hibernate scripts: dbus-send --system --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/acpi_LID org.freedesktop.Hal.Device.Rescan No difference on my system!
The HAL portion of this bug (and really where it should be fixed) is here: https://bugs.freedesktop.org/show_bug.cgi?id=6542
This should be fixed in yesterdays update. The fix was to add this : http://live.gnome.org/GnomePowerManager/Faq?action=subscribe#head-b8b1280115b0a51c2cc27b13a57121130ebf36cb
Yes -- fixed for me.
I spoke too soon. It is still an issue, but not quite as consistent as it was.
I've tried it several times now on a FC6 and it works like a charm for me now. Closing as works for me, please reopen if it's still causing problems for you. Thanks, Read ya, Phil
Still an intermittent problem for me with FC5. It happens pretty consistently if lid is closed and power cord unplugged before the laptop has completely finished suspending. Since this is the normal action when packing up quickly it is still an irritating but not fatal bug.
(In reply to comment #8) > Still an intermittent problem for me with FC5. I am sorry, FC5 is end of life now, so this bug cannot be fixed in FC5 anymore. It seems to be fixed for FC6 and beyond, therefore I close this bug now. Please reopen it, in case it is still a problem in FC6 or F7.