Hi,
I finally somewhat synchronized back the content of
http://en.opensuse.org/S2ram into README.s2ram-whitelist. IF there are
no objections, i'll commit it soon.
Index: README.s2ram-whitelist
===================================================================
RCS file: /cvsroot/suspend/suspend/README.s2ram-whitelist,v
retrieving revision 1.1
diff -u -r1.1 README.s2ram-whitelist
--- README.s2ram-whitelist 18 Mar 2006 14:34:08 -0000 1.1
+++ README.s2ram-whitelist 16 Jan 2007 19:33:44 -0000
@@ -1,6 +1,6 @@
HOWTO get suspend to RAM to work out of the box.
================================================
-Stefan Seyfried, March 2006
+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.
@@ -16,8 +16,12 @@
* 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
@@ -25,7 +29,7 @@
"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.
+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.
@@ -34,6 +38,15 @@
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
@@ -45,11 +58,10 @@
that these machines need, so if your machine is supported, suspending is
as easy as calling "s2ram".
-
How to use it?
---------------
-"make install", 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
+--------------
+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.
@@ -61,7 +73,7 @@
The workarounds can be activated from the s2ram commandline:
[EMAIL PROTECTED]:~> s2ram -h
-Usage: s2ram [-nhi] [-fsra]
+Usage: s2ram [-nhi] [-fspmrav]
Options:
-h, --help: this text.
@@ -73,15 +85,17 @@
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 investigation on an unknown machine is probably to
+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
@@ -93,36 +107,64 @@
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
-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").
+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 -i", so we can update
-the whitelist accordingly.
-
-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).
+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?
------------------------------------
-You can email me directly, [EMAIL PROTECTED], or send a mail to the
suspend-devel
-mailinglist at [EMAIL PROTECTED]
+Send a mail to the suspend-devel mailinglist at
[EMAIL PROTECTED] 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
--
Stefan Seyfried \ "I didn't want to write for pay. I
QA / R&D Team Mobile Devices \ wanted to be paid for what I write."
SUSE LINUX Products GmbH, Nürnberg \ -- Leonard Cohen
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel
