S2ram

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.

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
• saving the VBE state before suspend and restoring it after resume using vbetool

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.

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 a package for SUSE 10.1 is 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:

seife@susi:~> s2ram -h
Usage: s2ram [-nhi] [-fsra]

Options:
    -h, --help:       this text.
    -n, --test:       test if the machine is in the database.
                      returns 0 if known and supported
    -i, --identify:   prints a string that identifies the machine.
    -f, --force:      force suspending, even on unknown machines.

the following options are only available with --force:
    -s, --vbe_save:   save VBE state before suspending and restore after resume.
    -p, --vbe_post:   VBE POST the graphics card after resume
    -r, --radeontool: turn off the backlight on radeons before suspending.
    -a, --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 investigation 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. If it doesn't, try the following variations:

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

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 -s" both work on your machine), the in-kernel method ("-a") should be preferred over the userspace method ("-p" and "-s").

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?

You can email me directly, seife @ suse.de, or send a mail to the suspend-devel mailinglist at suspend-devel@lists.sourceforge.net.

Integration into other projects

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

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

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.

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.