There is a variety of mechanisms to enable your operating system to suspend to memory or to disk. To understand the difference between these systems, you need to know that there exists a suspend/resume implementation in the kernel (swsusp) and (typically) a set of additional tweaks to handle specific drivers/modules/hardware (ex: video card re-initialization).

There is a variety of mechanisms to enable your operating system to suspend to memory or to disk. To understand the difference between these systems, you need to know that there exists a suspend/resume implementation in the kernel (swsusp) and (typically) a set of additional tweaks to handle specific drivers/modules/hardware (ex: video card re-initialization).

+

+

* [[systemd]] provides commands for suspend to RAM, hibernate and a hybrid suspend using the kernel's native suspend/resume functionality. There are also mechanisms to add hooks to customize pre- and post-suspend actions.

* [[pm-utils]] is a set of shell scripts that encapsulate the kernel's suspend/resume functionality. It comes with a set of pre- and post-suspend tweaks and various hooks to customize the process.

* [[pm-utils]] is a set of shell scripts that encapsulate the kernel's suspend/resume functionality. It comes with a set of pre- and post-suspend tweaks and various hooks to customize the process.

−

* [[uswsusp]] also aims to provide programs that encapsulate the kernel's suspend/resume functionality with the additional tweaks necesarry. It also aims to provide a suspend-to-both functionality - this allows resuming from memory if battery is not depleted and resuming from disk if battery is completely depleted.

+

* [[uswsusp]] also aims to provide programs that encapsulate the kernel's suspend/resume functionality with the additional tweaks necessary. It also aims to provide a suspend-to-both functionality - this allows resuming from memory if battery is not depleted and resuming from disk if battery is completely depleted.

* [[TuxOnIce]] differs from pm-utils and uswsusp in that it attempts to directly patch the kernel's suspend/resume functionality to add more functionality than the default implementation. It therefore requires a custom kernel.

* [[TuxOnIce]] differs from pm-utils and uswsusp in that it attempts to directly patch the kernel's suspend/resume functionality to add more functionality than the default implementation. It therefore requires a custom kernel.

Line 24:

Line 24:

Note that the end goal of these packages is to provide binaries/scripts that can be invoked to perform suspend/resume. Actually hooking them up to power buttons or menu clicks or laptop lid events is left to other mechanisms. To automatically suspend/resume on certain power events, such as laptop lid close or battery depletion percentage, you may want to look into running [[Acpid]].

Note that the end goal of these packages is to provide binaries/scripts that can be invoked to perform suspend/resume. Actually hooking them up to power buttons or menu clicks or laptop lid events is left to other mechanisms. To automatically suspend/resume on certain power events, such as laptop lid close or battery depletion percentage, you may want to look into running [[Acpid]].

−

= Suspend methods =

+

== Suspend methods ==

These methods can be used to suspend/resume directly. pm-utils is also fairly generic, so its pm-suspend and pm-hibernate scripts can be configured to use any of these methods.

These methods can be used to suspend/resume directly. pm-utils is also fairly generic, so its pm-suspend and pm-hibernate scripts can be configured to use any of these methods.

−

== kernel ==

+

=== kernel ===

The most straightforward approach is to directly inform the in-kernel software suspend code (swsusp) to enter a suspended state; the exact method and state depends on the level of hardware support. On modern kernels, writing appropriate strings to [http://acpi.sourceforge.net/documentation/sleep.html /sys/power/state] is the primary mechanism to trigger this suspend. For example, let us study out how pm-utils does this.

The most straightforward approach is to directly inform the in-kernel software suspend code (swsusp) to enter a suspended state; the exact method and state depends on the level of hardware support. On modern kernels, writing appropriate strings to [http://acpi.sourceforge.net/documentation/sleep.html /sys/power/state] is the primary mechanism to trigger this suspend. For example, let us study out how pm-utils does this.

Line 56:

Line 56:

In general, it is possible that just installing pm-utils and invoking pm-suspend (which uses the kernel backend by default) just works for you. In some cases, you may need to force specific modules to be unloaded to make this work, as described in [[pm-utils#Advanced Configuration]].

In general, it is possible that just installing pm-utils and invoking pm-suspend (which uses the kernel backend by default) just works for you. In some cases, you may need to force specific modules to be unloaded to make this work, as described in [[pm-utils#Advanced Configuration]].

See [[Systemd#ACPI_power_management]] for additional information on configuring suspend/resume hooks. Also see {{ic|man systemctl}}, {{ic|man systemd-sleep}}, and {{ic|man systemd.special}}.

+

+

=== uswsusp ===

The uswsusp ('Userspace Software Suspend') package provides '''s2ram''', a wrapper around the kernel's suspend-to-RAM mechanism which perform some graphics adapter manipulations from userspace before suspending and after resuming. This includes:

The uswsusp ('Userspace Software Suspend') package provides '''s2ram''', a wrapper around the kernel's suspend-to-RAM mechanism which perform some graphics adapter manipulations from userspace before suspending and after resuming. This includes:

Line 71:

Line 81:

Since HAL is deprecated and KMS drivers can save the state of the grahic card directly without userspace quirks, '''s2ram''' development is discontinued and no further whitelist entries are accepted. If a KMS driver is in use, '''s2ram''' will directly suspend the machine.

Since HAL is deprecated and KMS drivers can save the state of the grahic card directly without userspace quirks, '''s2ram''' development is discontinued and no further whitelist entries are accepted. If a KMS driver is in use, '''s2ram''' will directly suspend the machine.

−

== tuxonice ==

+

=== tuxonice ===

[[TuxOnIce]] is a fork of the kernel implementation of suspend/resume that provides kernel patches to improve the default implementation. It requires a custom kernel to achieve this purpose. Since pm-utils is a set of shell scripts with a variety of hooks, it can be configured to use TuxOnIce as well.

[[TuxOnIce]] is a fork of the kernel implementation of suspend/resume that provides kernel patches to improve the default implementation. It requires a custom kernel to achieve this purpose. Since pm-utils is a set of shell scripts with a variety of hooks, it can be configured to use TuxOnIce as well.

−

= pm-utils configuration =

+

=== pm-utils configuration ===

−

−

{{Merge|pm-utils}}

−

'''pm-utils''' is suspend and powerstate settings framework implementing extensible hooks run in alphanumerical order as root from ''{/usr/lib/pm-utils/,/etc/pm/}{sleep.d/,power.d/}''. The suspend backend is specified by the SLEEP_MODULE configuration variable in ''/etc/pm/config.d'' and defaults to the kernel backend. The Arch Linux package ships with support for the following backends:

+

See [[pm-utils]].

−

pacman -Ql pm-utils | grep module.d

−

pm-utils /usr/lib/pm-utils/module.d/

−

pm-utils /usr/lib/pm-utils/module.d/kernel

−

pm-utils /usr/lib/pm-utils/module.d/tuxonice

−

pm-utils /usr/lib/pm-utils/module.d/uswsusp

−

Furthermore, '''pm-utils''' ships with its own video quirks database in ''/usr/lib/pm-utils/video-quirks/''.

−

However to be able to use the alternative suspend backends - uswsusp or tuxonice - the respective packages need to be installed

+

== Deciding between these options ==

−

*uswsusp - available in [[AUR]] under the name {{Package AUR|uswsusp-git}}

−

*tuxonice - available in [[AUR]] under the name {{Package AUR|linux-ice}}

−

= Deciding between these options =

+

=== Pm-utils framework or not? ===

−

−

== Pm-utils framework or not? ==

Directly calling the kernel backend method is significantly faster than calling '''pm-suspend''', since running all the hooks provided by the '''pm-utils''' framework invariable takes time. Even uswsusp is faster than '''pm-suspend'''. However, the recommended approach is to use '''pm-utils''' as it can properly:

Directly calling the kernel backend method is significantly faster than calling '''pm-suspend''', since running all the hooks provided by the '''pm-utils''' framework invariable takes time. Even uswsusp is faster than '''pm-suspend'''. However, the recommended approach is to use '''pm-utils''' as it can properly:

* set hardware clock

* set hardware clock

Line 100:

Line 98:

In fact, only the '''pm-utils''' approach can be called without special privileges, see [[pm-utils#Suspend.2FHibernate as regular user]]

In fact, only the '''pm-utils''' approach can be called without special privileges, see [[pm-utils#Suspend.2FHibernate as regular user]]

−

== Selecting the backend/method ==

+

=== Selecting the backend/method ===

* kernel - hooks provided by '''pm-utils''' (including video quirks) with kernel method. This is the recommended mechanism. It may require specific kernel modules to be unloaded before it will work properly. Searching on the arch linux bbs for your specific laptop is a good idea to discover these modules.

* kernel - hooks provided by '''pm-utils''' (including video quirks) with kernel method. This is the recommended mechanism. It may require specific kernel modules to be unloaded before it will work properly. Searching on the arch linux bbs for your specific laptop is a good idea to discover these modules.

Line 106:

Line 104:

* tuxonice - since it requires a kernel recompile, make sure you are getting a specific feature out of it that is not supported by the default kernel implementation.

* tuxonice - since it requires a kernel recompile, make sure you are getting a specific feature out of it that is not supported by the default kernel implementation.

−

−

−

== Pm-utils Internals ==

−

−

This outlines the internal actions when '''pm-suspend''' is run, describing how '''pm-utils''' gracefully falls back onto the kernel method if the requirements of other methods are not met.

−

−

$ pm-suspend

−

−

The first step is set-up preliminary variables and source parent scripts:

−

export STASHNAME=pm-suspend

−

export METHOD="$(echo ${0##*pm-} |tr - _)"

−

. "/usr/lib/pm-utils/pm-functions"

−

−

The variable ''METHOD'' is extracted from the executable name, ''suspend'' from '''pm-suspend''' and ''hibernate'' from '''pm-hibernate'''.

−

−

The location of runtime configuration parameters is defined in ''/usr/lib/pm-utils/pm-functions'' as ''PM_UTILS_RUNDIR="/var/run/pm-utils"'' and ''STORAGEDIR="${PM_UTILS_RUNDIR}/${STASHNAME}/storage"''. Therefore ''STORAGEDIR="/var/run/pm-utils/pm-suspend/storage"''; this is where pm-suspend will cache its configuration. Disabled hooks are stored as plain text files with the hook name prefixed by "''disable_hook:''". Configuration parameters are appended to the ''parameters'' file:

−

$ ls -lah /var/run/pm-utils/pm-suspend/storage/

−

-rw-r--r-- 1 root root 20 May 19 09:57 disable_hook:99video

−

-rw-r--r-- 1 root root 0 May 19 02:59 parameters

−

-rw-r--r-- 1 root root 247 May 19 02:59 parameters.rm

−

-rw-r--r-- 1 root root 9 May 19 02:59 state:cpu0_governor

−

-rw-r--r-- 1 root root 9 May 19 02:59 state:cpu1_governor

−

−

Then ''pm-functions'' will source the files located in ''/etc/pm/config.d/'' in addition to ''/usr/lib/pm-utils/defaults''. Upon returning, ''pm-functions'' will proceed to source the files specified by $SLEEP_METHOD as ''/usr/lib/pm-utils/module.d/$SLEEP_METHOD[...]'' if they exist:

−

for mod in $SLEEP_MODULE; do

−

mod="${PM_UTILS_LIBDIR}/module.d/${mod}"

−

[ -f "$mod" ] || continue

−

. "$mod"

−

done

−

−

Otherwise, if $SLEEP_MODULE is empty, ''do_suspend()'' will be set to the kernel backend as described above:

−

if [ -z "$SUSPEND_MODULE" ]; then

−

if grep -q mem /sys/power/state; then

−

SUSPEND_MODULE="kernel"

−

do_suspend() { echo -n "mem" >/sys/power/state; }

−

elif [ -c /dev/pmu ] && pm-pmu --check; then

−

SUSPEND_MODULE="kernel"

−

do_suspend() { pm-pmu --suspend; }

−

elif grep -q standby /sys/power/state; then

−

SUSPEND_MODULE="kernel"

−

do_suspend() { echo -n "standby" >/sys/power/state; }

−

fi

−

fi

−

−

Assuming $SLEEP_MODULE is not empty and '''uswsusp''' is specified, ''/usr/lib/pm-utils/module.d/uswsusp'' is executed. This script checks several requirements (these are the requirements for being able to use uswsusp):

The first function, ''add_before_hook'' disables the '''pm-utils''' hooks '''99video''' since this functionality is subsumed by '''s2ram'''.

−

The second function, ''add_module_help'', adds uswsusp-module-specific help, which in essence replaces the help function provided by '''99video'''.

−

−

−

Back to '''pm-suspend''':

−

command_exists "check_$METHOD" && command_exists "do_$METHOD"

−

"check_$METHOD"

−

This verifies that the ''check_suspend'' and ''do_suspend'' methods have been defined. The ''check_suspend'' method simply verifies that $SUSPEND_MODULE is not empty:

−

−

check_suspend() { [ -n "$SUSPEND_MODULE" ]; }

−

−

Lastly, '''pm-suspend''' must run all hooks that have not been disabled, sync file-system buffers, and run ''do_suspend'':

−

if run_hooks sleep "$ACTION $METHOD"; then

−

# Sleep only if we know how and if a hook did not inhibit us.

−

log "$(date): performing $METHOD"

−

sync

−

"do_$METHOD" || r=128

−

log "$(date): Awake."

−

−

The method ''run_hooks'' is a wrapper for ''_run_hooks'', which the case of pm-suspend is called as ''run_hooks sleep "suspend suspend"''. Given that:

−

PARAMETERS="${STORAGEDIR}/parameters"

−

PM_UTILS_LIBDIR="/usr/lib/pm-utils"

−

PM_UTILS_ETCDIR="/etc/pm"

−

The method ''_run_hooks'', will for each hook in ''"${PM_UTILS_LIBDIR}/$1.d"'' and ''"${PM_UTILS_ETCDIR}/$1.d"'', check that sleep has not been inhibited and update the runtime parameters stored in ''$PARAMETERS'' before running each hook via ''run_hook $hook $2''. In the case of Suspend-to-RAM, all the hooks in ''{/usr/lib/pm-utils/sleep.d/,/etc/pm/sleep.d/}'' will be enumerated, and ''run_hook'' will be passed the parameters ''$hook'' and "''suspend suspend''". The method ''run_hook'' uses the ''hook_ok'' function to verify that the hook has not been disabled before executing the hook with the "''suspend suspend''" parameters.

=== ACPI_OS_NAME ===

=== ACPI_OS_NAME ===

Line 200:

Line 117:

You might want to try other string if this one does not work.

You might want to try other string if this one does not work.

−

= Other Resources =

+

== Other Resources ==

*[http://suspend.sourceforge.net/ Uswsusp Home Page]

*[http://suspend.sourceforge.net/ Uswsusp Home Page]

*[http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface Advanced Configuration and Power Interface]

*[http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface Advanced Configuration and Power Interface]

Sleep mode can go by many different names, including Stand By, Sleep, and Suspend. When placed in this sleep mode, aside from the RAM which is required to restore the machine's state, the computer attempts to cut power to all unneeded parts of the machine. Because of the large power savings, most laptops automatically enter this mode when the computer is running on batteries and the lid is closed. (from Wikipedia:Sleep mode)

There is a variety of mechanisms to enable your operating system to suspend to memory or to disk. To understand the difference between these systems, you need to know that there exists a suspend/resume implementation in the kernel (swsusp) and (typically) a set of additional tweaks to handle specific drivers/modules/hardware (ex: video card re-initialization).

systemd provides commands for suspend to RAM, hibernate and a hybrid suspend using the kernel's native suspend/resume functionality. There are also mechanisms to add hooks to customize pre- and post-suspend actions.

pm-utils is a set of shell scripts that encapsulate the kernel's suspend/resume functionality. It comes with a set of pre- and post-suspend tweaks and various hooks to customize the process.

uswsusp also aims to provide programs that encapsulate the kernel's suspend/resume functionality with the additional tweaks necessary. It also aims to provide a suspend-to-both functionality - this allows resuming from memory if battery is not depleted and resuming from disk if battery is completely depleted.

TuxOnIce differs from pm-utils and uswsusp in that it attempts to directly patch the kernel's suspend/resume functionality to add more functionality than the default implementation. It therefore requires a custom kernel.

Note that the end goal of these packages is to provide binaries/scripts that can be invoked to perform suspend/resume. Actually hooking them up to power buttons or menu clicks or laptop lid events is left to other mechanisms. To automatically suspend/resume on certain power events, such as laptop lid close or battery depletion percentage, you may want to look into running Acpid.

Suspend methods

These methods can be used to suspend/resume directly. pm-utils is also fairly generic, so its pm-suspend and pm-hibernate scripts can be configured to use any of these methods.

kernel

The most straightforward approach is to directly inform the in-kernel software suspend code (swsusp) to enter a suspended state; the exact method and state depends on the level of hardware support. On modern kernels, writing appropriate strings to /sys/power/state is the primary mechanism to trigger this suspend. For example, let us study out how pm-utils does this.

In general, it is possible that just installing pm-utils and invoking pm-suspend (which uses the kernel backend by default) just works for you. In some cases, you may need to force specific modules to be unloaded to make this work, as described in pm-utils#Advanced Configuration.

systemd

See Systemd#ACPI_power_management for additional information on configuring suspend/resume hooks. Also see man systemctl, man systemd-sleep, and man systemd.special.

uswsusp

The uswsusp ('Userspace Software Suspend') package provides s2ram, a wrapper around the kernel's suspend-to-RAM mechanism which perform some graphics adapter manipulations from userspace before suspending and after resuming. This includes:

passing acpi_sleep=s3_bios to the kernel

passing acpi_sleep=s3_mode to the kernel

passing both of the above (acpi_sleep=s3_bios,s3_mode) to the kernel

POSTing the video card from userspace after resume using vbetool

saving the VBE state before suspend and restoring it after resume using vbetool

This is accomplished by a hardware whitelist maintained by HAL - s2ram translates the HAL database options into s2ram parameters.

Since HAL is deprecated and KMS drivers can save the state of the grahic card directly without userspace quirks, s2ram development is discontinued and no further whitelist entries are accepted. If a KMS driver is in use, s2ram will directly suspend the machine.

tuxonice

TuxOnIce is a fork of the kernel implementation of suspend/resume that provides kernel patches to improve the default implementation. It requires a custom kernel to achieve this purpose. Since pm-utils is a set of shell scripts with a variety of hooks, it can be configured to use TuxOnIce as well.

pm-utils configuration

Deciding between these options

Pm-utils framework or not?

Directly calling the kernel backend method is significantly faster than calling pm-suspend, since running all the hooks provided by the pm-utils framework invariable takes time. Even uswsusp is faster than pm-suspend. However, the recommended approach is to use pm-utils as it can properly:

Selecting the backend/method

kernel - hooks provided by pm-utils (including video quirks) with kernel method. This is the recommended mechanism. It may require specific kernel modules to be unloaded before it will work properly. Searching on the arch linux bbs for your specific laptop is a good idea to discover these modules.