-
Notifications
You must be signed in to change notification settings - Fork 3
/
README.s2ram-whitelist
88 lines (76 loc) · 4 KB
/
README.s2ram-whitelist
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
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