Bug 216459 - pm-utils - an instant DoS with suspend/hibernate on many machines
Summary: pm-utils - an instant DoS with suspend/hibernate on many machines
Alias: None
Product: Fedora
Classification: Fedora
Component: pm-utils
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-11-20 16:54 UTC by Michal Jaegermann
Modified: 2015-03-05 01:17 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2007-01-23 14:17:43 UTC

Attachments (Terms of Use)

Description Michal Jaegermann 2006-11-20 16:54:19 UTC
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):

Comment 1 Phil Knirsch 2007-01-23 14:17:43 UTC
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...

Comment 2 Michal Jaegermann 2007-01-23 19:04:24 UTC
> 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.

Note You need to log in before you can comment on or make changes to this bug.