Suspend to RAM

From openSUSE

s2ram - Getting suspend to RAM to work out of the box

The goal of the s2ram binary is to get suspend to RAM working out of the box on as many machines as possible.

Important

The package is called suspend or uswsusp and comes installed as standard with most distributions.

If your version of s2ram does not have all the options described in this document, try getting a newer version, e.g. from http://suspend.sf.net or here.

The -m and -v options have been added pretty recently.

Background

Suspend to RAM is working on many machines already - which means that the machine comes back to life and resumes operation, the keyboard works and the harddisk is still accessible - but to get video working and the backlight back on, you need the one or other "dirty trick". There are some different workarounds for that:

• 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
• getting the video mode number before suspend and setting the same video mode after resume using vbetool
• saving the VBE state before suspend and restoring it after resume using vbetool
• saving the PCI config space of the VGA card before suspend and restoring it after resume

Since kernel 2.6.16, the acpi_sleep parameter can be set during runtime (no reboot needed) in /proc/sys/kernel/acpi_video_flags, with "1" for s3_bios, "2" for s3_mode and "3" for both. More information about those hacks can be found in the kernel-source (usually installed in /usr/src/linux) in the file Documentation/power/video.txt.

There are machines that will not resume when using a framebuffer console. Recent Dell and HP models for example very often fall into this category.
You can disable the framebuffer in your bootloader configuration by passing "vga=0" to the kernel. The configuration for grub is often found in /boot/grub/menu.lst.
If your machine only works without framebuffer, please tell us about this in your report.

If none of the methods described here seem to work, it is important to check if the machine is completely dead on resume or only the video is not resumed properly. A good way to check this is to start with a minimal system (init=/bin/bash), run s2ram -f, and after resume, when the display is still off, check if the "Caps Lock" key still works (you should see a reaction of the Caps Lock LED on the keyboard). If it does, it is most likely really a video initialization problem. If it doesn't, then it is most likely a BIOS problem or a bug in the Linux kernel.

Why s2ram?

• vbetool usage for saving the VBE state is not easy: you have to dump the state of the card to a temporary file, before suspend, and restore it from there after resume. This can of course be put into a wrapper script, but having it in one binary is even easier.
• you need to know if your machine needs a workaround and which one it needs. s2ram contains a database of known working machines and the workarounds that these machines need, so if your machine is supported, suspending is as easy as calling "s2ram".

OK, enough talk! Let's get started!

Where can i get it?

s2ram is part of the suspend project hosted on sourceforge and packages for various distributions are available.

How to use it?

Install it, then just call s2ram. If your machine is in the whitelist, it should suspend to RAM. Be careful though, some broken drivers need to be unloaded before suspend and reloaded after resume. If you just want to know if your machine is known and which workarounds (if any) will be used, call s2ram -n.

S2ram is also integrated in the latest builds of powersaved: if the suspend package is installed, powersaved checks before startup (using s2ram -n) if the machine is capable of suspend to RAM and depending on the result enables or disables "suspend button".

My machine is not in the whitelist, what can i do?

Just find out which workaround is needed for your machine (if any), then get this knowledge to us, together with the output of s2ram -i.

The workarounds can be activated from the s2ram commandline:

marek@mantisha:~> /usr/sbin/s2ram -h
Usage: s2ram [options]
  -h, --help            this text.
  -V, --version                         version information
  -n, --test            test if the machine is in the database.
  -i, --identify        prints a string that identifies the machine.
  --nofbsuspend         do not suspend the framebuffer (debugging only!).
  --force               force suspending, even on unknown machines.

The following options are only available with --force:
  --vbe_save            save VBE state before suspending and restore after resume.
  --vbe_post            VBE POST the graphics card after resume.
  --vbe_mode            get VBE mode before suspend and set it after resume.
  --radeontool          turn off the backlight on radeons before suspending.
  --pci_save            save the PCI config space for the VGA card.
  --acpi_sleep <acpi_sleep>     set the acpi_sleep parameter before suspend
                        1=s3_bios, 2=s3_mode, 3=both

The options should be mostly self-explaining. Note that you need to use the -f option on all unknown machines, then add the proper workarounds. Option -a needs an additional numeric argument from 1 to 3, specifying s3_bios, s3_mode or both.

The best way to start investigating an unknown machine is probably to boot with init=/bin/bash at the boot prompt into a minimal environment, then do:

 # mount /proc
 # mount /sys
 # s2ram -f

if the first try already succeeds, everything is fine. Send us the output of s2ram -i, and don't forget to mention that plain s2ram -f was enough even from text mode (see #How to contact the authors of s2ram?). If it doesn't, try the following variations:

• s2ram -f -a 3
• s2ram -f -a 2
• s2ram -f -a 1
• s2ram -f -p -m
• s2ram -f -p -s
• s2ram -f -m
• s2ram -f -s
• s2ram -f -p
• s2ram -f -a 1 -m
• s2ram -f -a 1 -s

If none of those combinations work, start again but add the "-v" switch.

Note: mixing up the "-a" options and the vbetool options ("-p", "-m", "-s") is normally only a measure of last resort, it usually does not make much sense. One exception to this rule seems to appear with the latest 64bit ThinkPads, which often work only with "-a 1 -m" in 64bit mode (x86_64).

One of those should hopefully get your machine back to life (and the backlight back on). Once you have found a combination that works, send us that information together with the output of s2ram -i. If you find several combinations that work (e.g. "s2ram -f -a 3" and "s2ram -f -p -m" both work on your machine), the in-kernel method ("-a") should be preferred over the userspace method ("-p", "-m" and "-s").

If you found a combination that works, please verify that it works in both cases before reporting success to the s2ram developers:

• when issuing s2ram from console
• when issuing s2ram from X itself

It is normal that the contents of the text console are gone after using "-p" and "-m", on the framebuffer console this can easily be solved by switching consoles once. Although this might be better with "-s", still "-m" should be the preferred option if it works.

Note that you really should try this from a minimal text mode console. Reports that it works there are much more useful than those done only from within X. You also do not get adverse side effects like shutting down immediately after resume from running powermanagement daemons.

If you found out what options are best for you and you want to use s2ram immediately, you can add options to /usr/lib/pm-utils/defaults, like: S2RAM_OPTS="-f -a 3". (Is there better place for this, like somewhere in /etc ?)

Everything works fine, but the Backlight of my machine stays on during suspend

If your machine has a Radeon graphics card and the light does not switch off during suspend, try adding the "-r" switch to your combination of switches. This is known to help ThinkPads of the '30 series (T30, X31, R32,... ). If your machine does not have a Radeon graphics chip, then this option does not make sense.

My machine is in the whitelist but it does not work, what can i do?

There are some wildcard matches in the whitelist, and it is possible that they might match on machines that are different than the originally tested ones. The procedure is about the same as with "My machine is not in the whitelist": find out which options your particular machine needs and send us this information together with the output of s2ram -i, so we can update the whitelist accordingly.

How to contact the authors of s2ram?

Send a mail to the suspend-devel mailinglist at suspend-devel@lists.sourceforge.net. If this does not work for some reason, please create a bugreport at https://bugzilla.novell.com, even if you are not using openSUSE (just file a bug against the highest numbered openSUSE product, component "Mobile Devices"). If you email me directly, seife @ suse.de, your mail might well get lost in the incoming mail pile and the mailing list or bugzilla usually provides faster response times and more knowledgeable people.

Important: We cannot read your mind, nor do we know what you tried, so please state

• what options you gave to s2ram to make it work
• that you tested it from both X and the text console mode (ctrl-alt-f1 or the minimal mode described here)
• if there is any special setup you needed to do to make it work, also mention it.
• the output of s2ram -n

Testing without installing anything

Sitsofe Wheeler found out, that many machines can be tested without installing anything, just by using the openSUSE 10.2 Live DVD.

Up to date packages for various distributions

SUSE / openSUSE

Up to date packages can be found in Stefan Seyfried's Buildservice project, at http://software.opensuse.org/download/home:/seife or directly in openSUSE Factory. The package is called "suspend". For the latest packages, you might need to install the libx86 package which is provided at the same place.

Debian

Tim Dijkstra maintains the debian packages (called uswsusp) at http://packages.debian.org/unstable/admin/uswsusp

Gentoo

A Gentoo package, called suspend, is available in portage. See the Gentoo Linux Handbook for help on installing packages in Gentoo.

Other

If you know of updated packages for other distributions, please update this Article or notify me on the suspend-devel mailinglist, so i can update it.

Integration into other projects (or "How to get the GUI buttons working")

openSUSE 10.2+ / pm-utils

openSUSE 10.2 and later, as well as many other recent distributions, use pm-utils as suspend framework, so the configuration variables explained here can be used to give the s2ram options.

Powersave

s2ram is integrated in the latest version of powersaved, there are some configuration variables that let you select the workaround if your machine is not yet in the whitelist. They are explained here.

SUSE 10.1

SUSE 10.1 uses powersaved, so the configuration variables explained here can be used to specify workarounds.

Useful hints

These are just the "Tips and Tricks" that i found out when trying to get machines to suspend to RAM. Use with caution ;-)

Intel Graphics Chipsets

Machines with Intel graphics chipsets often work with "s2ram -f -a3", even when using vesafb framebuffer. If "s2ram -f -a3" does not work (for example on Dell machines), often "s2ram -f -p -m" works well.

Newer intel Xorg drivers seem to have problems with "-s" (VBE_SAVE), so "-m" (VBE_MODE) should be used if at all possible with them. See https://bugzilla.novell.com/show_bug.cgi?id=229603 . Generally speaking, VBE_MODE is preferable to VBE_SAVE.

ATI Graphics Chipsets

Lately many machines i came across with ATI Radeon graphics chipsets did not work with any framebuffer (usually they hung inside the BIOS, not even capslock did work after trying to resume). They often worked fine with "vga=0" and "s2ram -f -p -m" or "s2ram -f -p -s".

NVidia Graphics Chipsets

Resuming to a graphical X after suspend to ram will often fail when using the opensource nv driver because it is not yet known how to reinitialise NVIDIA cards. After a few special steps a machine with NVidia card should work with "s2ram -f" when using the binary only drivers. See the detailed instructions here: NVidia Suspend HOWTO.

APIC problems

I have seen many machines lately that needed the APIC disabled on the kernel command line with "noapic", otherwise they would not resume or behave strange after resume (timer interrupts no longer working etc.), so this is something to try out. It should be no longer necessary with recent kernels, openSUSE 10.2 already should not need it anymore.

The machine immediately shuts down after resume!

s2ram is primary a "low level" system tool. To use it in "real production" environments, you should incorporate it into your power management setup, e.g. into your acpid scripts (they can trigger suspend on the press of the sleep button for example). If you are using a distribution that uses powersave, please read the Powersave_s2ram page.

This should be fixed since at least kernel 2.6.20, so workarounds should no longer be necessary.

Don't give up!

Sometimes, getting suspend to RAM working is not as straightforward as we all would like. If you'd like to read about an example of what people had to go through, read the following report from Bugzilla. Winfried is my hero :-) Also it is quite important to know if the machine is resuming from suspend to RAM but "only" leaving the display off or if it is hanging completely. See the ACPI_Suspend_debugging article for instructions on how to find out.