| 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, 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? |
| -------------------------------------------------- |
| 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] [-fspmrav] |
| |
| 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 |
| -m, --vbe_mode: get VBE mode before suspend and set it 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 |
| -v, --pci_save: save the PCI config space for the VGA card. |
| |
| 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". If it doesn't, try the following variations: |
| s2ram -f -a 1 |
| s2ram -f -a 2 |
| s2ram -f -a 3 |
| 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 combination works, 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 of those combinations 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 |
| methods ("-p", "-m" and "-s"). |
| |
| Verify all combinations in both cases when 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. |
| |
| Note that there are some issues that might make suspend fail regardless of |
| video, such as IDE drives not properly waking up (using the latest -mm |
| kernel sometimes helps here) and APIC issues (booting with "noapic" to |
| verify those is sometimes useful). |
| |
| 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 -n" (better than |
| "s2ram -i", because we can see what entry actually matched your machine), |
| 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, |
| 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 |