Differences between revisions 16 and 65 (spanning 49 versions)
Revision 16 as of 2007-08-07 13:41:38
Size: 8399
Editor: ?timrichardson
Comment:
Revision 65 as of 2021-07-01 07:26:48
Size: 7486
Editor: PhilHands
Comment: update dead link
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## Please edit system and help pages ONLY in the moinmaster wiki! For more
## information, please see MoinMaster:MoinPagesEditorGroup.
##master-page:Unknown-Page
##master-date:Unknown-Date
##acl MoinPagesEditorGroup:read,write,delete,revert All:read
Line 9: Line 4:

This page gathers bits of information about getting software suspend to work in Debian. Because software suspend is still experimental, it is not enabled by default on most machines. Depending on your system, a few more steps are needed to get suspend partially or fully working. However, many people find that it works quite well now.
This page gathers bits of information about getting software suspend to work in Debian. Because the core system components change rapidly among Debian versions, software suspend works differently on different versions of Debians. This page is divided according to Debian versions from new to old.
Line 14: Line 8:
=== Suspend under lenny using Hal (example, kernel 2.6.21) === <<TableOfContents()>>
Line 16: Line 10:
== Debian Jessie and newer (8 and newer) ==
Line 17: Line 12:
The Gnome Power Manager must be installed to enable suspend menu entries on the System -> Shut Down dialog. With systemd, `pm-utils` and its hooks are not used any more, instead there's `systemd-suspend`. To suspend use:
Line 19: Line 14:
However, power management events are not only initiated by the menu system. The computer's power button may be pressed, for example.
A key package for Lenny's power management is HAL which watches for ACPI events. HAL has a built-in ACPI module, so you don't need to install the separate ACPI packages. However, the separate ACPI packages which provide acpid are usually still selected. HAL works with acpid if it is present; acpid is mature and it's use with HAL is common.

Power management events are handled by a "policy manager", which decides what do to once a power management event is generated. gnome-power-manager is a policy manager. But it still doesn't actually do any real work, such as suspending the system.

The policy manager (gnome power manager) sends its request for action back to HAL, and HAL then looks for power management scripts to do the real work.
Installing HAL with no power management software will log messages to /var/log/messages, but nothing else will happen. You can try this by removing the pm-utils package.


The package pm-utils is a package of power management software. It is actually a "front" to give common interface for HAL; it stands between HAL and actually suspending the system. pm-utils is designed for specific customisations to be "hooked" into it. This means that scripts in the directory /usr/lib/pm-utils/sleep.d are executed at suspend and resume. (pm-utils actually looks first in /etc/pm/sleep.d, but in the default Debian configuration, these directories are empty).

hibernate and "thaw" are handled almost the same.


This is getting a bit complicated, so I will summarise where we are:
You choose "suspend".
the gnome-power-manager sends a message to HAL, and HAL is pleased to find scripts from pm-utils: it calls pm-suspend. It may pass pm-suspend some specific instructions based on hardware quirks (see below)

pm-suspend runs any scripts it finds to prepare for suspension. Some kernel modules are unloaded, for example.Then it calls a program to cause suspend to happen, requiring the OS to talk to the motherboard. pm-suspend can ask to ask the kernel to suspend, but first it looks for the program s2ram (using the kernel is a fall-back).

(note: the man page for pm-suspend is interesting and easy to understand)

All this message sending may seem like a lot of work, but by putting HAL in the centre, some big advantages are gained. One is that HAL includes a growing database of hardware, and it can use "quirks" to tweak the suspend, hibernate and resume operations. HAL therefore lets all Linux distributions share this hardware-specific knowledge. This database of quirks is in the Debian package hal-info.

==== About pm-utils ====

We stick with the script pm-suspend as the topic to explore further.
It is a shell script, in /usr/sbin/pm-suspend.
What it does is logged to /var/log/pm-suspend.log

pm-suspend runs a number of shell scripts that do specific tasks to prepare for suspend, and then executes the the suspend.
The suspend operation is optionally handled by the Linux kernel, but pm-suspend looks first to see if the package uswsusp is installed (more accurately, it looks for the program called s2ram). If it finds s2ram, it uses this. Using s2ram seems to be the preferred way of working.


You should also have a look at the log file mentioned above.

On my system, I see from the log file that /usr/lib/pm-utils/sleep.d is the source of about ten scripts executed when a suspend occurs.
They are executed in alphabetical order. You will notice that the same scripts are executed on a resume, but in reverse order.
There is a script to handle network connections: it calls the gnome package network manager, so you should probably be using it.


==== Summary of relevant packages for HAL and pm-utils ====
Here is a list of packages linked to power management. Only HAL seems to be necessary for gnome to work.

+ '''HAL''' Central to the modern power management approach

+ '''hal-info''' rules for specific hardware

+ '''pm-utils''' required for the configuration discussed here. Key scripts are placed in /usr/sbin and /usr/lib/pm-utils/sleep.d

+ '''uswsusp''' optional but recommended by pm-utils. the pm-utils scripts look for the executables in this package. Try to see if suspend and hibernate works without it first (more details below)

+ '''powermgmt-base''' provides some status scripts that are relied upon by other parts of Gnome and Debian, but it is not central to the operation of suspend and resume.

+ '''ACPI-Support''' optional

+ '''acpid''' optional (HAL will use apcid if it is present)

+ '''acpi''' not needed

+ '''libacpi0''' not needed

+ '''hibernate''' not needed

==== Tips on using s2ram from uswsusp package ====
The uswsusp package is optional, but highly recommended.
s2ram comes with a database of known computers, but your computer configuration may not be included.
To find out, from a root terminal, execute
Line 88: Line 15:
s2ram
}}}
to see if it works with your computer.
You may get "unknown computer".
In that case, try using the force option:
{{{
s2ram -f
systemctl suspend
Line 97: Line 18:
If this works, then you need to make the -f option the default for pm-utils. === In Gnome ===
One option is to use the Gnome "suspend-button" extension at https://extensions.gnome.org/extension/826/suspend-button/
Line 99: Line 21:
edit near the top of the file /usr/lib/pm-utils/defaults
to change the line with the options for s2ram. See this example:
Another option, under Gnome shell, is to simply press ALT before clicking the shutdown button in the user menu.

=== In KDE Plasma ===
[[KDE]] already has a suspend button in its normal shutdown menu, though it may instead be labelled as "Sleep" in Plasma 5.16 and newer. Cases where it might not appear are if DebianPkg:powerdevil or DebianPkg:upower aren't installed. systemd is used if available, but it's not required.

Note that if power management is suspended by an application, the system may not suspend automatically, even if configured otherwise in your Energy Saving settings. This is often done by media players, for instance, to keep the screen from dimming. The Battery and Brightness item in your system tray will let you know if power management is suspended, and what process is currently suspending it.

=== Disable suspend and hibernation ===

For systems which should never attempt any type of suspension, these targets can be disabled at the systemd level with the following:
{{{
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
}}}

To re-enable hibernate and suspend use the following command:
{{{
sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target
}}}

A modern '''alternative''' approach for disabling suspend and hibernation is to create `/etc/systemd/sleep.conf.d/nosuspend.conf` as
{{{
[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no
}}}
The above technique works on Debian 10 Buster and newer. See systemd-sleep.conf(5) for details.

If you just want to prevent suspending when the lid is closed you can set the following options in `/etc/systemd/logind.conf`:
Line 103: Line 53:
#######################################################################
# The following options require the uswsusp package being installed

# what options should be passed to s2ram?
# see http://en.opensuse.org/S2ram for more information
# for hal 0.5.9 and up don't set this option to get the options supplied
# by HAL
 S2RAM_OPTS="-f"
[Login]
HandleLidSwitch=ignore
HandleLidSwitchDocked=ignore
Line 113: Line 58:
Then run `systemctl restart systemd-logind.service` or reboot.
Line 114: Line 60:
Now, suspend should work when using the uswsusp package. More information is available in the manpage: `man logind.conf`
Line 116: Line 62:
This is a useful advanced reference: [http://gentoo-wiki.com/HOWTO_Software_Suspend_v2 Gentoo HOWTO_suspend] == Debian Wheezy (7) ==
A very notable change is that HAL is phased out. If you still have the `hal` package installed, you should remove it or it will interference with `pm-utils` during suspend.
Line 118: Line 65:
== Information for older kernels == If the suspend / resume works well on your system, you are lucky and no need to read anything on this page. Or else, the first step to debug is to enable debugging for pm-utils, who control the suspend and resume process.
Line 120: Line 67:
Older versions of Debian do not use HAL as discussed above. They rely on the ACPI packages, and scripts handling acpi events. === Enabling Debugging for pm-utils ===
The log of suspend and resume processes are in file `/var/log/pm-suspend.log`. It contains moderately verbose information by default. More information can be enabled for debugging by inserting line `export PM_DEBUG=true` into the beginning of file `/usr/lib/pm-utils/pm-functions`.
Line 122: Line 70:
The following scripts were needed to get suspend to ram working on a ThinkPad X22 running linux-image 2.6.14-2 and tracking unstable. === Fixing corrupted video on resume ===
A very common issue found after the computer resumes is corrupted video (or black screen, or no LCD backlight). The first step is to check whether the system is still running, which can be simply done by pressing the Capslock button and check whether the Capslock LED is changing accordingly. If the system is still running, in most cases we need to add a video quirk for your video card.
Line 124: Line 73:
Script '''/etc/acpi/events/custom_sleepbtn'''
{{{
event=button/sleep
action=/etc/acpi/actions/custom_sleep.sh
}}}
Debian now has kernel mode setting (KMS) enabled by default for most Intel, nVidia and ATI video cards. But pm-utils' video quirk does support KMS yet. So in most cases you should try disabling KMS first. The detail steps for your specific video card can be found on the KernelModesetting page.
Line 130: Line 75:
Script '''/etc/acpi/events/custom_lid'''
{{{
event=button/lid
action=/etc/acpi/actions/custom_sleep.sh
}}}
After disabled KMS, if the video after resume still corrupts, you can try to suspend the system by using some video quirks. Read the manpage of the `pm-suspend` program for a very detailed explanation of all the quirks available, and try the combinations of them from command-line. If you successfully find one combination of quirks that works for your system, you can add them into `/usr/lib/pm-utils/video-quirks` to make them permanent. At the same time, please help to file a bug against the `pm-utils` package with a patch about your changes so it can benefit the mass.
Line 136: Line 77:
Script '''/etc/acpi/actions/custom_sleep.sh'''
{{{
# enable xscreensaver
source /proc/`pidof xscreensaver`/environ && xscreensaver-command -lock
A common issue found on systems upgrading from old versions of Debian is the enabling of quirk-s3-bios freezes the system during suspend. If your system freezes during suspend, check the pm-suspend.log carefully after enabled debugging and make sure quirk-s3-bios is not used.
Line 141: Line 79:
## optional: eject all pcmcia devices
#cardctl eject || true
== Kernel testing facility ==
The kernel has a Suspend testing facility [[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0e7d56e3d9d7e37c79d0e05ffb3994e34beb3bbc|changelog]].
Line 144: Line 82:
# go to sleep
echo mem > /sys/power/state
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend core code. Namely, writing one of the strings below to this file causes the suspend code to work in one of the test modes defined as
follows:
Line 147: Line 85:
}}}  freezer :: test the freezing of processes
 devices :: test the freezing of processes and suspending of devices
 platform :: test the freezing of processes, suspending of devices and platform global control methods(*)
 processors :: test the freezing of processes, suspending of devices, platform global control methods and the disabling of nonboot CPUs
 core :: test the freezing of processes, suspending of devices, platform global control methods, the disabling of nonboot CPUs and suspending of platform/system devices
(*) These are ACPI global control methods on ACPI systems
Line 149: Line 92:
Make sure the files you create in /etc/acpi/actions are executable: Then, if a suspend is started by normal means, the suspend core will perform its normal operations up to the point indicated by given test level. Next, it will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state. Writing "none" to /sys/power/pm_test turns the testing off.
Line 151: Line 95:
{{{
$ sudo chmod +x /etc/acpi/actions/custom_sleep.sh
}}}
When open for reading, {{{/sys/power/pm_test}}} contains a space-separated list of all available tests (including "none" that represents the normal functionality) in which the current test level is indicated by square brackets.
Line 155: Line 97:
=== Internal Links === The actual message (for googlers) are {{{suspend debug: Waiting for 5 seconds}}}.
Line 157: Line 99:
 * Self:ACPI
 * Self:OffAndOnAgain
 * Self:Hibernate
== Internal Links ==
 * [[ACPI]]
 * OffAndOnAgain
 * [[Hibernation]]
 * ScreenLockingOnSleep
 * ConfigurePowerButton
 * [[PageFragmentLidSuspendSystemd/jessie]]
Line 161: Line 107:
=== External Links ===
The first two links refer to old approaches.
 * [http://www.columbia.edu/~ariel/acpi/acpi_howto.html ACPI HowTo]
 * [http://tldp.org/HOWTO/ACPI-HOWTO/ Another ACPI HowTo]
These are more modern links (> kernel 2.6.20)
 * [http://people.freedesktop.org/~hughsient/quirk/index.html About HAL and power management from freedesktop.org]
 * [http://gentoo-wiki.com/HOWTO_Software_Suspend_v2 Gentoo HOWTO_suspend: about the uswsusp package]
== External Links ==

 * [[https://wiki.archlinux.org/index.php/Software_suspend|ArchWiki - Uswsusp]]
 * [[https://wiki.gentoo.org/wiki/Suspend_and_hibernate|Gentoo Wiki - Suspend and hibernate]]
 * [[https://help.gnome.org/users/gnome-power-manager/|Gnome Power Manager Manual]] - The FAQ is interesting
 * [[http://en.opensuse.org/Category:Power_Management|OpenSuse pages on power management]]
 * [[https://01.org/node/3721|Best practice to debug Linux* suspend/hibernate issues]]
Line 169: Line 115:
CategoryHardware  CategoryHardware

Help on software suspend

This page gathers bits of information about getting software suspend to work in Debian. Because the core system components change rapidly among Debian versions, software suspend works differently on different versions of Debians. This page is divided according to Debian versions from new to old.

For more reading material, see also the links at the bottom of this page about hibernate and suspend.

Debian Jessie and newer (8 and newer)

With systemd, pm-utils and its hooks are not used any more, instead there's systemd-suspend. To suspend use:

systemctl suspend

In Gnome

One option is to use the Gnome "suspend-button" extension at https://extensions.gnome.org/extension/826/suspend-button/

Another option, under Gnome shell, is to simply press ALT before clicking the shutdown button in the user menu.

In KDE Plasma

KDE already has a suspend button in its normal shutdown menu, though it may instead be labelled as "Sleep" in Plasma 5.16 and newer. Cases where it might not appear are if powerdevil or upower aren't installed. systemd is used if available, but it's not required.

Note that if power management is suspended by an application, the system may not suspend automatically, even if configured otherwise in your Energy Saving settings. This is often done by media players, for instance, to keep the screen from dimming. The Battery and Brightness item in your system tray will let you know if power management is suspended, and what process is currently suspending it.

Disable suspend and hibernation

For systems which should never attempt any type of suspension, these targets can be disabled at the systemd level with the following:

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

To re-enable hibernate and suspend use the following command:

sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target

A modern alternative approach for disabling suspend and hibernation is to create /etc/systemd/sleep.conf.d/nosuspend.conf as

[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no

The above technique works on Debian 10 Buster and newer. See systemd-sleep.conf(5) for details.

If you just want to prevent suspending when the lid is closed you can set the following options in /etc/systemd/logind.conf:

[Login]
HandleLidSwitch=ignore
HandleLidSwitchDocked=ignore

Then run systemctl restart systemd-logind.service or reboot.

More information is available in the manpage: man logind.conf

Debian Wheezy (7)

A very notable change is that HAL is phased out. If you still have the hal package installed, you should remove it or it will interference with pm-utils during suspend.

If the suspend / resume works well on your system, you are lucky and no need to read anything on this page. Or else, the first step to debug is to enable debugging for pm-utils, who control the suspend and resume process.

Enabling Debugging for pm-utils

The log of suspend and resume processes are in file /var/log/pm-suspend.log. It contains moderately verbose information by default. More information can be enabled for debugging by inserting line export PM_DEBUG=true into the beginning of file /usr/lib/pm-utils/pm-functions.

Fixing corrupted video on resume

A very common issue found after the computer resumes is corrupted video (or black screen, or no LCD backlight). The first step is to check whether the system is still running, which can be simply done by pressing the Capslock button and check whether the Capslock LED is changing accordingly. If the system is still running, in most cases we need to add a video quirk for your video card.

Debian now has kernel mode setting (KMS) enabled by default for most Intel, nVidia and ATI video cards. But pm-utils' video quirk does support KMS yet. So in most cases you should try disabling KMS first. The detail steps for your specific video card can be found on the KernelModesetting page.

After disabled KMS, if the video after resume still corrupts, you can try to suspend the system by using some video quirks. Read the manpage of the pm-suspend program for a very detailed explanation of all the quirks available, and try the combinations of them from command-line. If you successfully find one combination of quirks that works for your system, you can add them into /usr/lib/pm-utils/video-quirks to make them permanent. At the same time, please help to file a bug against the pm-utils package with a patch about your changes so it can benefit the mass.

A common issue found on systems upgrading from old versions of Debian is the enabling of quirk-s3-bios freezes the system during suspend. If your system freezes during suspend, check the pm-suspend.log carefully after enabled debugging and make sure quirk-s3-bios is not used.

Kernel testing facility

The kernel has a Suspend testing facility changelog.

Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend core code. Namely, writing one of the strings below to this file causes the suspend code to work in one of the test modes defined as follows:

freezer
test the freezing of processes
devices
test the freezing of processes and suspending of devices
platform
test the freezing of processes, suspending of devices and platform global control methods(*)
processors
test the freezing of processes, suspending of devices, platform global control methods and the disabling of nonboot CPUs
core
test the freezing of processes, suspending of devices, platform global control methods, the disabling of nonboot CPUs and suspending of platform/system devices

(*) These are ACPI global control methods on ACPI systems

Then, if a suspend is started by normal means, the suspend core will perform its normal operations up to the point indicated by given test level. Next, it will wait for 5 seconds and carry out the resume operations needed to transition the system back to the fully functional state. Writing "none" to /sys/power/pm_test turns the testing off.

When open for reading, /sys/power/pm_test contains a space-separated list of all available tests (including "none" that represents the normal functionality) in which the current test level is indicated by square brackets.

The actual message (for googlers) are suspend debug: Waiting for 5 seconds.