resume from suspend drops back into resume

[fangorious]

I have an HP nw8240 laptop, and after building deb packages of the latest Ati
proprietary drivers both suspend and resume work fine under gnome. But with KDE
(both the one packaged with breezy and the 3.5 packages on kubuntu.org) when I
resume from a suspend, the laptop is on for maybe 5 seconds before is suspends
again. I have to hold down the powerkey while it's resuming to hard power down
the machine and do a full boot to break the cycle. I'm currently running the 3.5
KDE packages from kubuntu.org.

[Jonathan Riddell (jr)]

Is this KDE specific? Either test under gnome or run sudo pmi action hibernate or sudo pmi
action suspend from a console while logged out of KDE.

[fangorious (fangorious-deactivatedaccount)]

it is specific to KDE, I don't have the cyclical suspend-on-resume if I suspend while logged into
gnome. I suspend by closing the laptop lid (set /etc/acpi/events/lidbtn to run /etc/acpi/suspend.sh).
I don't think I've ever seen the problem with hibernate, but I'll double check hibernating logged in
to each desktop and while not logged in. I'll also try to check the pmi suspend command for all three
situations too.

[fangorious (fangorious-deactivatedaccount)]

I just tested the pmi command for both suspend and hibernate in all three
situations (logged into gnome, logged into kde, not logged in). It is limited to
suspending while logged into kde.

[fangorious (fangorious-deactivatedaccount)]

Well, I'm not sure what happened, but suspending by closing the lid (in gnome and kde, and not
logged in) now leads to the suspend-on-resume problem. But using the pmi command to hibernate
from all three and suspend from gnome and not-logged-in still works fine.

[fangorious (fangorious-deactivatedaccount)]

I'm going ahead and moving this to acpi-support. It currently seems like that's a more appropriate place for this.

[fangorious (fangorious-deactivatedaccount)]

I've determined that this is due to using gnome-power-manager 0.2.8.1 from the breezy backports repository. Hopefully this will be addressed in dapper's version of g-p-m.

[Daniel Silverstone (dsilvers)]

Is there any chance you can verify if this still happens with dapper's g-p-m?

[fangorious (fangorious-deactivatedaccount)]

how many packages would I need from dapper? I don't want to upgrade to dapper due to some reports of suspend/hibernate not working on my laptop model.

[Daniel Silverstone (dsilvers)]

I belive this has something to do with the fact that the gnome settings daemon responds to a sleep button push and suspends the machine. As a result, you get both g-s-d and g-p-m trying to suspend the laptop which results in two separate suspend/resume cycles

[fangorious (fangorious-deactivatedaccount)]

It could be something like that, but shouldn't that only suspend once on resume, then, rather than an endless loop? Also, this laptop (HP nw8240) doesn't technically have a sleep button, just scancodes (I have Fn+F3 mapped to hibernate in gconf:apps->gnome_settings_daemon->keybindings) and a lidbtn (with /etc/acpi/events/lidbtn configured to run /etc/acpi/sleep.sh, which when run manually does not exhibit this bug) . You may want to sync up with Matther Garret on this one. I just looked into it and there are way too many dependencies to update for me to try the dapper version.

[Daniel Silverstone (dsilvers)]

This is very odd indeed. There should be no appreciable difference between invoking sleep.sh manually or by acpid's events system. That the bug exhibited itself only in KDE and then later exhibited itself in gnome and not-logged-in situations also is very confusing.

Do you have a spare partition where you could make a fresh install of breezy and record carefully what you do and whether or not it enters this re-suspend loop?

[fangorious (fangorious-deactivatedaccount)]

I managed to repartition the drive to get dapper on. This loop problem seems to be gone. Hibernate doesn't work after updating to acpi-support 0.57 today, but that's not particular to g-p-m

[Daniel Silverstone (dsilvers)]

Reporter confirms this bug is not present in dapper