SDB:Suspend to RAM
|Update to version: 13.1-13.2|
This article needs to be tested for a newer version. If you are using this guide on the newer version and you find the guide up-to-date to this version, please add the version number to the Knowledge bar. Please refer to version related jobs: SDB pages for more information.
- 1 Background
- 2 Why s2ram?
- 3 Using s2ram
- 4 Troubleshooting
- 5 How to contact the authors of s2ram?
- 6 Testing without installing anything
- 7 Useful hints
- 8 See also
- 9 External links
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.
- 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".
Install it, then just call
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 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
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:
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.
If you found out what options are best for you and you want to use s2ram immediately, check SDB:Pm-utils#Configuration.
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.
Short answer: don't. Please read the box on top of this page: s2ram is deprecated and additional machines will not be added to the whitelist. Use the HAL / upower / pm-utils whitelists instead.
Testing without installing anything
Many machines can be tested without installing anything, just by using the live media.
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".
IBM/Lenovo T60p (2613ETU) with FGLRX seems to suspend/resume properly with X running with S2RAM_OPTS="-f -a 1 -s". Neither the s2ram or hal defaults work properly.
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: SDB:NVidia Suspend HOWTO.
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.
Problem due to VirtualBox drivers
Suspend can hang if vboxdrv is loaded, to work around that they have to be unloaded before running suspend(rcvboxdrv stop). To do that automatically you can put a script in /etc/pm/sleep.d/ like this example.
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 SDB:Powersave_s2ram page.
This should be fixed since at least kernel 2.6.20, so workarounds should no longer be necessary.
Restarting PCI cards
After suspending some peripherals (like wireless network cards) may not properly activate.
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 SDB:ACPI_suspend_debugging article for instructions on how to find out.
- Linux suspend project on Sourceforge