State of software for Suspend to RAM/Disk ?

Posted on by lucas

Dear readers,

I am the mostly happy owner of a Dell Latitude D610 (the one with the ATI video card), running Debian Etch. I installed the hibernate package to try to get Suspend to RAM and to Disk to work, and Suspend to Disk worked out of the box. But Suspend to RAM didn’t work (garbled screen at resume).

I never bothered to investigate this until today, when I discovered that acpi-support provides the same functionality, and works both for Suspend to RAM and to Disk ! I’m happier now, but I would like to understand, and the world of ACPI and Suspend to RAM/Disk is very difficult to grasp for newcomers.

What is the story behind hibernate and acpi-support ? Why was this duplication of effort needed ? Also, it seems that gnome-power-manager and kpowersave provide the same functionality. Why can’t they just call the relevant acpi-support or hibernate scripts ? How do those different implementations compare (what are their main differences ?) ? Looking at the packages content, it seems that hibernate tries to be generic, while acpi-support gave up, and handles each and every laptop model differently. Correct ? Also, hibernate seems to be handling a few things better, like getting my network interface back up after hibernation.

Finally, the last question: how do one debug Suspend issues, when it fails to work ? Is there a document somewhere explaining that ?

9 thoughts on “State of software for Suspend to RAM/Disk ?”

  1. I have an ASUS A2500D with an ati card. I can’t have X back if DRI is enabled, and I can’t play a fullscreen movie when DRI is disabled.

    Hope this helps ;-)

  2. Actually, gnome-power-manager uses hal, which, in turn uses, in this order, powersave, pmi, pm-hibernate, hibernate or write the appropriate string directly to /sys/power/state.
    Note it uses pm-hibernate and hibernate only for suspend to disk, not suspend to ram.
    acpi-support could probably be added in this.

    Anyways, back to your problem of suspend to RAM, I’m a lucky owner of a Vaio S70 that *doesn’t* need anything more than echo mem > /sys/power/state to suspend to ram correctly AND come back to life properly. Though now my battery is almost dead I only suspend to disk…

  4. Unfortunately, most ACPI BIOSes are extremely buggy – largely because the most popular ASL compiler in use today reports critical errors as warnings. De/Recompiling the BIOS on this laptop, a Dell D410, reports a measly 14 warnings. Doing it with a Tyan Transport VX50 gives 1 error and 18 warnings. I could continue to do it with more machines, but you get the idea.

    The broken state of ACPI is largely due to the number of broken BIOSes in use – and it therefore makes sense to do a dirty per-device-workaround mechanism since nobody remotely follows the specification correctly.

  5. Hi,

    I use µswsusp on my Toshiba Satellite M40X for both suspend-to-disk and suspend-to-ram.

    Although I have been using successfully suspend2 patch and hibernate script for some time the laptop, I noticed it refused to work without I could find any explanation.

    I have thus switched to µswsusp which allows easy suspend-to-disk and suspend-to-ram, and has several advantages over suspend2:
    * Does not require patching the kernel (though requires a kernel >= 2.6.17)
    * Suspend and resume processes are far more quick as with hibernate
    * No confguration file has to be edited to find the modules to be unloaded or services stopped before suspending

    I just add to add:
    Option “VBERestore” “true”
    to my Xorg.conf so that resume from suspend-to-disk works ok.

    Cheers,
    Julien

  8. Btw, kpowersave >= 0.7.x will also use HAL as only mechanism to do suspend to (disk|ram), exactly like gnome-power-manager.

    So you get a nice, layered architecture:
    HAL, providing the mechanism like Suspend() and Hibernate() over D-Bus, and a policy manager, like g-p-m or kpowersave which decides when to run suspend and hibernate.
    Below HAL (see the scripts /usr/lib/hal/scripts/linux/hal-system-power-*), you can choose whatever powermanagement backend works best for you.
    Beginning with HAL 0.5.9 the officially supported one will be pm-utils (http://lists.freedesktop.org/mailman/listinfo/pm-utils),
    There are currently hibernate (coming from suspend2), acpi-support (coming from Ubuntu), powersaved

  9. gnome-power-manager does use hibernate on my laptop.

    Hibernate is quite smart, it can work with various different low-level suspend mechanisms, depending on which are available.

    I used to use suspend2 on my previous laptop, and it worked great (with Radeon graphics; free driver, couldn’t test with the driver from ATI because they don’t support my Radeon)

    On my new Dell, Intel graphics, I’m using uswsusp, which is the youngest of the suspend implementations available. Works good for me, it even suspends into my encrypted swap partition (you can’t do that with plain ACPI afaik).
    I had to disable the VBETool hack in /etc/hibernate/ram.conf

    Oh, and I used to need to un-kill my wireless before suspending; the ipw1394 driver used to have issues when loading while the kill switch is enabled. But that was fixed in the meantime.

    The hibernate docs and configuration files have some hints on what might be causing problems with suspend. The most common trick in debugging is to try without an X-server first, and try to remove drivers that might be causing problems (hibernate comes with a blacklist of drivers known to not suspend/resume correctly).

    For various reasons, I recommend the use of hibernate; one being that it has ready to use tweaks such as starting a fresh xserver to reinitalize graphics hardware on resume, vbetool but especially for this driver blacklist.

    The only grief I have is that gnome-power-manager always seems to think that my suspend had failed, while it was successful. Seems like somewhere in that intransparent gnome-power-manager – dbus – hal – hibernate chain an error code was returned.

Comments are closed.