HOWTO get suspend to RAM to work out of the box. ================================================ Stefan Seyfried, January 2007 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 * 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 tarball 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. 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". How to use it? -------------- Install it, then just call s2ram. If your machine is in the whitelist or if the kenel supports KMS (Kernel Mode Switch), 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. My machine is not in the whitelist, what can i do? -------------------------------------------------- After the suspend version 1.0, with KMS support, no new machines will be added to the whitelist. You don't need to do nothing, the new kernels support KMS. 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, you can also email me directly, seife @ suse.de, but the mailing list usually provides faster response times and more knowledgeable people. Any additions / corrections to this document are always welcome. There is also a similar document available online (which might even contain newer information) as http://suspend.sf.net/s2ram-support.html. Have a lot of fun... Stefan Seyfried