FeistySuspendOverview
|
Size: 5471
Comment:
|
Size: 5533
Comment: Removed bolding, and started on inconsistencies section.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 16: | Line 16: |
| === Console (acpi events) === | === Default (acpi events) === |
| Line 39: | Line 39: |
| '''There does not appear to be a default handler for the ''hibernatebtn'' acpi event.''' |
|
| Line 49: | Line 47: |
| '''The ''powermanagement-interface'' scripts execute the ''acpi-support'' scripts with an override for any other policy.''' | The ''powermanagement-interface'' scripts execute the ''acpi-support'' scripts with an override for any other policy. |
| Line 55: | Line 53: |
| '''The software suspend policy of ''gnome-power-manager'' is actually handled by ''hal''.''' | The software suspend policy of ''gnome-power-manager'' is actually handled by ''hal''. |
| Line 104: | Line 102: |
* There does not appear to be a default handler for the ''hibernatebtn'' acpi event. * ''acpi-support'' will use ''uswsusp'' for hibernation but not sleep. |
There seems to be quite a bit of discussion about suspend-to-ram and suspend-to-disk support in Feisty. I think a large portion of the disagreements are rooted in the fact the overall suspend process and support are largely inconsistent and undocumented. Therefore, in an attempt to foster useful discussion, I will try to document the overall method of how software suspend works in Ubuntu.
Relevant Packages
Package name |
Responsibilities |
acpi-support |
Default suspend and hibernate policy. |
powermanagement-interface |
Front-end to acpi-support policy. |
gnome-power-manager |
Alternate policy provider. |
hal |
gnome-power-manager policy backend. |
kpowersave |
Alternate policy provider. |
Starting software suspend
There are multiple methods of starting a software suspend procedure. Each is associated with a different user-interface state.
Default (acpi events)
In the absence of any other overriding policy, acpi-support has full control over the software suspend process.
acpi suspend events |
ibm-hibernatebtn |
ibm-sleepbtn |
panasonic-hibernatebtn |
panasonic-sleepbtn |
sony-hibernate |
sony-sleep |
tosh-hibernate |
tosh-sleep |
sleepbtn |
There are two categories of acpi suspend events, and they respectively execute two scripts:
Suspend category |
Associated script |
hibernate |
/etc/acpi/hibernate.sh |
sleep |
/etc/acpi/sleep.sh |
These scripts are either executed directly, or in-directly by a mapping of the third-party sleep/hibernate button events to the normal sleepbtn event.
GDM
GDM has menu-items specifically for "hibernate" and "suspend" (sleep). These call the powermanagement-interface directly via the following commands:
Menu item |
Command executed |
hibernate |
/usr/sbin/pmi action hibernate |
suspend |
/usr/sbin/pmi action sleep |
The powermanagement-interface scripts execute the acpi-support scripts with an override for any other policy.
Gnome
gnome-power-manager is the official policy and user-interface for power management in Gnome. When it is running, the several power management related acpi-support scripts specifically disable themselves. Their normal actions will not occur except when specifically requested via a "force" command-line option.
The software suspend policy of gnome-power-manager is actually handled by hal.
KDE
Software suspend policy
Once a software suspend has been requested, some program must perform the "policy" for it. That is, actually ensure the system is in a suitable state for suspension. And later, return the system to (roughly) the same state it was before the software suspend occurred.
acpi-support
These much maligned scripts now have a long history behind them, and apparently fairly rich support for a variety of hardware. However, they are also almost completely Ubuntu specific.
The two earlier mentioned scripts, /etc/acpi/hibernate.sh and /etc/acpi/sleep.sh handle the heavy lifting. Documenting their every contortion is beyond the scope of this article; however, the overall process is as follows:
Step # |
/etc/acpi/hibernate.sh |
/etc/acpi/sleep.sh |
1 |
Ensure ACPI_HIBERNATE is enabled in /etc/default/acpi-support. |
Ensure ACPI_SLEEP is enabled in /etc/default/acpi-support. |
2 |
(no acpi events call hibernate) |
Defer to alternate policy, or check for override. |
3 |
|
Lock the screen. |
4 |
/etc/acpi/prepare.sh - prepare system for suspend |
|
5 |
Spin down hard drives. |
Disable hard drives' DMA. |
6 |
hibernate via uswsusp or suspend1 |
sleep via suspend1 |
7 |
Disable laptop_mode |
Reset and enable the DMA of the hard drives. |
8 |
/etc/acpi/resume.sh - reverse the suspend preparation |
|
hal
As hal is designed to be operating system agnostic, there is a (mostly dummy) front-end handler script initially called and then a specific worker script:
Power event |
Initial script |
Linux-specific script |
hibernate |
/usr/lib/hal/scripts/hal-system-power-hibernate |
/usr/lib/hal/scripts/linux/hal-system-power-hibernate-linux |
suspend (sleep) |
/usr/lib/hal/scripts/hal-system-power-suspend |
/usr/lib/hal/scripts/linux/hal-system-power-suspend-linux |
These scripts have several bugs and inconsistencies between them. (Free easy bug-fixing opportunity here!) However, in terms of Ubuntu, a selection process for what will perform the hiberate/suspend is performed:
powermanagement-interface
powersaved
(hibernate only) freedesktop's pm-utils
uswsusp
hibernate (suspend2)
acpi-support
Direct to /sys/power/state sysfs interface.
In a default Ubuntu installation, powermanagement-interface is installed and therefore will always win. This results in hal handing off policy back to acpi-support.
kpowersave
Kernel suspend technologies
Inconsistencies
There does not appear to be a default handler for the hibernatebtn acpi event.
acpi-support will use uswsusp for hibernation but not sleep.
Alternatives
Suspend2
FeistySuspendOverview (last edited 2008-08-06 16:20:09 by localhost)