Description of problem:
There are whole classes of machines where syspend-to-disk, a.k.a
hibernate, may work fine but suspend-to-RAM, a.k.a suspend will
do a suspend part but it will never wake up. This is the case,
for example, on x86_64 installations where suspend-to-RAM is
currently broken on a kernel level (but, apparently, pretty close
to what should be functioning). It may be also the situation on
various i386 laptop with a user beeing, to a great extent, on the
mercy of a BIOS. Possibly also happens that "Suspend" works but
"Hibernate" fails even if I am not aware of examples.
OTOH if gnome-power-manager is installed then one gets on a deskop
both "Suspend" and "Hibernate" buttons and it is easy, by
a mistake or by mischief, hit a "wrong" one. Closing a laptop lid
may also cause an immediate crash because a default configuration
of actions in gnome-power-manager was incorrect for the given situation
and missed. It appears that the only way out is to deinstall
gnome-power-manager and loose both.
In truth it is easy to make an offending action "toothless". It
is enough to add in /etc/pm/config something like:
plus an explanation in a comment, and change pm_main() in
/etc/pm/functions to have
if [ "$DISABLE_SUSPEND" != "yes" ] ; then
pm-pmu --suspend || echo -n "mem" > /sys/power/state
if [ "$DISABLE_HIBERNATE" != "yes" ] ; then
echo -n "platform" > /sys/power/disk
echo -n "disk" > /sys/power/state
in obvious places. Then by editing this config file an admin may
prevent nasty results of an incorrect action. Possibly changes
to pm_main() could be more radical but proposed ones look safe
in a chain of before-and-after events and worked fine in my quick
A package script may, and really should, edit accordingly that
configuration if we now that "Suspend" for sure will fail like on
Can we also have at least a symlink /etc/sysconfig/power-managment-config,
say, pointing to /etc/pm/config? At least then it will be in
an expected place too and easier to find.
Version-Release number of selected component (if applicable):
Both points look really nice. I have them both in the latest development package.
Read ya, Phil
PS: The final idea would be to get to a point where we can use as much info as
we can get about the machine to determine automatically if that machine can
reliably suspend/hibernate (ofc while still being able to "forcefully" enable or
disable it). But thats still some time away...
> Both points look really nice.
The situation changed in the meantime a bit in that sense that mine
x86_64 test box is doing a "creditable" suspend and restore. It takes
a long while before it actually gets into a usable state, despite of
the fact that a picture of a desktop shows up rather quickly, i.e.
with whatever displays actually functioning. Also a text console
after such experiment is uniformly white but X display seems to be
fine. Even a console can be restored after a bit of mucking around.
So maybe an automatic switch off for a suspend on x86_64 is
a bit too much?
OTOH with two x86 laptops I have here one is doing suspend to RAM
if 'acpi_sleep=s3_bios noapic' is passed to a kernel and the other
one steadfastly refuses to restore video after a suspend no matter
what. I went through the whole list from http://en.opensuse.org/S2ram
and no dice. Making sure that suspend is not attempted on this
machine, even by a mistake, is the only sensible option. "Hibernate"
works there just fine.