1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
|
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
|