Posts Tagged ‘suspend’

Suspend doesn’t know its working

Wednesday, February 6th, 2008

Often, when I have suspended by Zepto Znote 3215W, I get a little message at resume that suspend failed, which is weird as the laptop has just been suspended and successfully resumed.

Suspend failed message

It started with Linux 2.6.24.

Kernel 2.6.24 also seems to have broken some ACPI modules, as this now happens:

# acpi -V
No support for device type: battery
No support for device type: thermal
No support for device type: ac_adapter

I used to only get the error for “thermal” with kernel 2.6.23.

Suspend / hibernate problems in new Debian Testing install

Thursday, January 31st, 2008

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.