pm-utils: hibernate/suspend do not work right

[Antonio Lopez]

I own an ASUS P3-P5G43 (Intel GMA X4500 graphics) barebone running Mythbuntu 10.04 amd64. The following pm-utils commands work bad as shown:

- pm-hibernate:

the PC appears to correctly hibernate, but when trying to wake-up it only does a normal boot.

- pm-suspend:

It suspends the right way only the first time. Subsequent tries are ignored.

In both failure cases it seems no relevant info is written to pm-hibernate/suspend logs.

For suspend/hibernate purposes using MythTV I have set up the following script:

/etc/pm/sleep.d/01_mythtv:

#!/bin/bash

. "${PM_FUNCTIONS}"

case "$1" in
 suspend|hibernate)
 killall mythfrontend.real &> /dev/null
 killall mythwelcome &> /dev/null
 service mythtv-backend stop &> /dev/null
 service lirc stop &> /dev/null
 rmmod dvb_usb_dib0700 &> /dev/null
 ;;

 resume|thaw)
 modprobe dvb_usb_dib0700 &> /dev/null
 service lirc start &> /dev/null
 service mythtv-backend start &> /dev/null
 sleep 3
 sudo -u <mi_usuario> mythfrontend &> /dev/null
 ;;
esac

I will provide any additional debugging info upon request.

Regards,

[Ruslan (rulet3)]

 Thank's a lot for your script. When mythtv 0.24 was running on my system(Ubuntu 10.10) and during power loss it wasn't come to hibernate while running other programs such as firefox or openoffice it hibernates. I am using apcupsd to control apc ups(I have deleted gnome-power-manager after I have customized it through it's gui, because it is not working as I need and it's duplicates apcupsd functions), and these scripts https://wiki.archlinux.org/index.php/APC_UPS#Link_the_hibernate_script_for_apcupsd_to_use_it for hibernation when power loss.
I don't know if it's a bug of mythtv or pam-utils or generally system bug.

[Ruslan (rulet3)]

 So using your script it hibernates now when power loss and running mythtv.

[Ruslan (rulet3)]

 Hmm... but doesn't restore on wake up, don't know why yet, system jus shows menu "automatical login" or as a user and when even whe I choose one of the login option the system doesn't login, helps complete shutdown.

[Ruslan (rulet3)]

 But it doesn't affects on any other program, I have run in the same time a few applications -- broser, videoplayer, text-editor e.t. and it's hibernates and wake up correctly without using any additional scripts to those which I've mentioned.
 So I just can make a conclusion that it's a mythtv bug when using ups. During a usual manually system hibernate with mythtv it's work correctly.

[Gibby (gibby)]

What is the output of cat /proc/acpi/wakeup

[Antonio Lopez (amlopezalonso)]

Here:

Device S-state Status Sysfs node
P0P2 S4 disabled
P0P3 S4 disabled
P0P1 S4 disabled pci:0000:00:1e.0
UAR1 S4 disabled pnp:00:0c
USB0 S4 disabled pci:0000:00:1d.0
USB1 S4 disabled pci:0000:00:1d.1
USB2 S4 disabled pci:0000:00:1d.2
USB3 S4 disabled
EUSB S4 disabled pci:0000:00:1d.7
USB4 S4 disabled pci:0000:00:1a.0
USB5 S4 disabled pci:0000:00:1a.1
USB6 S4 disabled pci:0000:00:1a.2
USBE S4 disabled pci:0000:00:1a.7
P0P4 S4 disabled pci:0000:00:1c.0
P0P5 S4 disabled
P0P6 S4 disabled
P0P7 S4 disabled pci:0000:00:1c.3
P0P8 S4 disabled pci:0000:00:1c.4
P0P9 S4 disabled pci:0000:00:1c.5

[Antonio Lopez (amlopezalonso)]

Forgot commenting the previous output was after doing a normal boot (not after suspending/hibernating).

[Gibby (gibby)]

So it looks like your computer only supports S4 which is Hibernation. Also you have nothing enabled to wake up from S4 to enable say usb0 you just do the following.

echo USB0 /proc/acpi/wakeup

[Antonio Lopez (amlopezalonso)]

Nope. In despite of what it is spitted out by wakeup I swear it supports both S2RAM, S2DISK (both states are reached but the former works once only and the latter does not wake-up right).

Also are you sure "echo USB0 /proc/acpi/wakeup" has a proper syntax? I would understand "echo USB0 > /proc/acpi/wakeup" has it but I'm not even sure this shall work in a non-attribute virtual file like that.

[Thomas Mashos (tgm4883)]

We really do appreciate you opening this ticket to help improve Mythbuntu, but it needs to be closed for a number of reasons. The biggest one is that upstream has moved on to a new version and believes this to be fixed. Could you please verify if this issue still exists in the latest version?

Please do not let the closing of this ticket dissuade you from opening a new ticket if this (or any other) problem occurs with the newer versions.