Suspend / hibernate problems in new Debian Testing install

MenuI’ve had quite a bit of problems getting suspend and hibernate to work in Gnome on my new Zepto Znote 3215W.
The problem was that Gnome Power Manager simply refused to suspend or hibernate.
The actual functions of suspend or hibernation works great, with a minimum of fiddling. The Gnome Power Manager comes with a handful of wrapper scripts around the uswsusp programs s2disk and s2ram. The pm-hibernate script works out of the box from the command line as root. The system resumes correctly afterwards.
The laptop isn’t on the whitelist for s2ram, but it works with the –force flag, and that is easily automated by creating a file /etc/pm/config.d/s2ram with the line

S2RAM_OPTS=--force

and making the file executable. That will cause the pm-suspend script to pass –force to s2ram as default. Again, the system resumes correctly.
The problem was that when I tried to suspend or hibernate though the context menu of the Power Manager applet, I immediately got a dialog with the text:

Sleep Problem
Your computer failed to suspend.
Check the help file for common problems.

It happened so fast that no attempt at suspending could possibly have been made.
One track I followed was that the applet uses HAL to do the actual suspend/hibernate and HAL will only do that if it believes the laptop is capable of it. That can be checked by running the command:

lshal | grep power_management

I currently, after I solved my problems, get this output:

$ lshal | grep power_management
  power_management.acpi.linux.version = '20070126'  (string)
  power_management.can_hibernate = true  (bool)
  power_management.can_suspend = true  (bool)
  power_management.can_suspend_hybrid = true  (bool)
  power_management.can_suspend_to_disk = true  (bool)
  power_management.can_suspend_to_ram = true  (bool)
  power_management.is_powersave_set = false  (bool)
  power_management.quirk.none = true  (bool)
  power_management.type = 'acpi'  (string

To get HAL to recognise the laptop I have made a file
/usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-zepto.fdi
with this content:

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
  <device>
    <match key="system.hardware.vendor" prefix="ZEPTO">
      <match key="system.hardware.product" string="ZNOTE">
             <merge key="power_management.quirk.none" type="bool">true</merge>
      </match>
    </match>
  </device>
</deviceinfo>

and restarted HAL and logged out and in again. That should, as far as I have understood, whitelist the laptop in HAL by affirming that pm-suspend doesn’t need any additional options to work.
It didn’t make any difference, though. I still got the error message when trying to suspend from the applet’s context menu.
At this point I was about to give up. One last search on google brought up something new, however. There’s another level of permission checks involved, which is specified in the file /etc/dbus-1/system.d/hal.conf. In this file I found, among many other things, these lines:

  <!-- This configuration file specifies the required security policies
       for the HAL to work. -->

and

  <!-- Debian groups policies -->
  <policy group="powerdev">
    <allow send_interface="org.freedesktop.Hal.Device.SystemPowerManagement"/>
    <allow send_interface="org.freedesktop.Hal.Device.LaptopPanel"/>
  </policy>

which seem to indicate that I need to belong to the “powerdev” group to be able to use these functions.
I added myself to the group, logged out, logged in again, and everything worked.
This is the kind of experience that leaves you feeling a bit stupid. Totally unjustified, because I’m not to blame, but after having spend so much time looking in other directions, the solution is so simple.
Now the problem is solved, I hope to be able to use many of the useful functions of the Gnome Power Manager, such as automatic hibernation in low power situations.
I have notices another little thing that has changed. When I used the Fn-F4 and Fn-F5 keys to adjust the backlight on the display, I got a little on screen display, but it didn’t do anything, it just sat there. After I’m in the “powerdev” group, the on screen display actually shows an indicator of how the backlight is changed.


Comments

One response to “Suspend / hibernate problems in new Debian Testing install”

  1. Thanks for sharing this. It took me several hours to solve the problem to implement suspend on my Intel 965 desktop. I also found http://wiki.debian.org/Suspend very useful to understand the process.
    From what I have learned, HAL is the core of this process as it intercepts both ACPI and Gnome-Power-Manager events and then transfers the control to specific scripts that do the real job. Among the many scripts available, pm-utils are the recommended. So that HAL calls pm-suspend. Now, pm-suspend runs scripts to prepare for suspension and then either calls the kernel to suspend or calls another software that can handle specific instructions or quirks; this is the package uswsusp (userspace software suspend) that provides s2ram. This s2ram can be fed with instructions (quirks) from the pm-suspend defaults file (I used /usr/lib/pm-utils/defaults. Now, as from HAL 0.5.9, HAL can also pass the the options that pm-suspend will send to s2ram, if the hardware is recognized, in this case, I think, pm-tools default editing is not needed.
    In my case after verifying that suspend was successful with s2ram -f -a2, I edited /usr/lib/pm-utils/defaults to pass those parameters to s2ram. Then I verified that pm-suspend worked… checked Suspend from the Gnome applet and then from the power-off button. Finally, I could go to bed.
    However, I first tried to create /etc/pm/config.d/s2ram to pass the options but it didn’t work with pm-suspend as you described.
    Thanks.
    Ramon

Leave a Reply

Your email address will not be published. Required fields are marked *