FeistySuspendOverview

Differences between revisions 1 and 2
⇤ ← Revision 1 as of 2006-11-29 12:57:12 →
Size: 576
Editor: 66-233-137-79
Comment: Initial draft layout and rationale.
← Revision 2 as of 2006-11-29 14:10:30 → ⇥
Size: 5501
Editor: 66-233-137-79
Comment: Documented suspend instigators and policy.
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
|| '''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. ||
Line 6: Line 13:

There are multiple methods of starting a software suspend procedure. Each is associated with a different user-interface state.

=== Console (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.

'''There does not appear to be a default handler for the ''hibernatebtn'' acpi 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 ===
Line 7: Line 60:

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:

  1. ''powermanagement-interface''
  1. ''powersaved''
  1. ('''hibernate only''') freedesktop's ''pm-utils''
  1. ''uswsusp''
  1. ''hibernate'' (suspend2)
  1. ''acpi-support''
  1. 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 ===
Line 10: Line 104:
== Alternatives ==
=== Suspend2 ===

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.

Console (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.

There does not appear to be a default handler for the hibernatebtn acpi 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:

  1. powermanagement-interface

  2. powersaved

  3. (hibernate only) freedesktop's pm-utils

  4. uswsusp

  5. hibernate (suspend2)

  6. acpi-support

  7. 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

Alternatives

Suspend2

CategoryNeedsExpansion

FeistySuspendOverview (last edited 2008-08-06 16:20:09 by localhost)