Root/
1 | Some warnings, first. |
2 | |
3 | * BIG FAT WARNING ********************************************************* |
4 | * |
5 | * If you touch anything on disk between suspend and resume... |
6 | * ...kiss your data goodbye. |
7 | * |
8 | * If you do resume from initrd after your filesystems are mounted... |
9 | * ...bye bye root partition. |
10 | * [this is actually same case as above] |
11 | * |
12 | * If you have unsupported (*) devices using DMA, you may have some |
13 | * problems. If your disk driver does not support suspend... (IDE does), |
14 | * it may cause some problems, too. If you change kernel command line |
15 | * between suspend and resume, it may do something wrong. If you change |
16 | * your hardware while system is suspended... well, it was not good idea; |
17 | * but it will probably only crash. |
18 | * |
19 | * (*) suspend/resume support is needed to make it safe. |
20 | * |
21 | * If you have any filesystems on USB devices mounted before software suspend, |
22 | * they won't be accessible after resume and you may lose data, as though |
23 | * you have unplugged the USB devices with mounted filesystems on them; |
24 | * see the FAQ below for details. (This is not true for more traditional |
25 | * power states like "standby", which normally don't turn USB off.) |
26 | |
27 | You need to append resume=/dev/your_swap_partition to kernel command |
28 | line. Then you suspend by |
29 | |
30 | echo shutdown > /sys/power/disk; echo disk > /sys/power/state |
31 | |
32 | . If you feel ACPI works pretty well on your system, you might try |
33 | |
34 | echo platform > /sys/power/disk; echo disk > /sys/power/state |
35 | |
36 | . If you have SATA disks, you'll need recent kernels with SATA suspend |
37 | support. For suspend and resume to work, make sure your disk drivers |
38 | are built into kernel -- not modules. [There's way to make |
39 | suspend/resume with modular disk drivers, see FAQ, but you probably |
40 | should not do that.] |
41 | |
42 | If you want to limit the suspend image size to N bytes, do |
43 | |
44 | echo N > /sys/power/image_size |
45 | |
46 | before suspend (it is limited to 500 MB by default). |
47 | |
48 | |
49 | Article about goals and implementation of Software Suspend for Linux |
50 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
51 | Author: Gábor Kuti |
52 | Last revised: 2003-10-20 by Pavel Machek |
53 | |
54 | Idea and goals to achieve |
55 | |
56 | Nowadays it is common in several laptops that they have a suspend button. It |
57 | saves the state of the machine to a filesystem or to a partition and switches |
58 | to standby mode. Later resuming the machine the saved state is loaded back to |
59 | ram and the machine can continue its work. It has two real benefits. First we |
60 | save ourselves the time machine goes down and later boots up, energy costs |
61 | are real high when running from batteries. The other gain is that we don't have to |
62 | interrupt our programs so processes that are calculating something for a long |
63 | time shouldn't need to be written interruptible. |
64 | |
65 | swsusp saves the state of the machine into active swaps and then reboots or |
66 | powerdowns. You must explicitly specify the swap partition to resume from with |
67 | ``resume='' kernel option. If signature is found it loads and restores saved |
68 | state. If the option ``noresume'' is specified as a boot parameter, it skips |
69 | the resuming. If the option ``hibernate=nocompress'' is specified as a boot |
70 | parameter, it saves hibernation image without compression. |
71 | |
72 | In the meantime while the system is suspended you should not add/remove any |
73 | of the hardware, write to the filesystems, etc. |
74 | |
75 | Sleep states summary |
76 | ==================== |
77 | |
78 | There are three different interfaces you can use, /proc/acpi should |
79 | work like this: |
80 | |
81 | In a really perfect world: |
82 | echo 1 > /proc/acpi/sleep # for standby |
83 | echo 2 > /proc/acpi/sleep # for suspend to ram |
84 | echo 3 > /proc/acpi/sleep # for suspend to ram, but with more power conservative |
85 | echo 4 > /proc/acpi/sleep # for suspend to disk |
86 | echo 5 > /proc/acpi/sleep # for shutdown unfriendly the system |
87 | |
88 | and perhaps |
89 | echo 4b > /proc/acpi/sleep # for suspend to disk via s4bios |
90 | |
91 | Frequently Asked Questions |
92 | ========================== |
93 | |
94 | Q: well, suspending a server is IMHO a really stupid thing, |
95 | but... (Diego Zuccato): |
96 | |
97 | A: You bought new UPS for your server. How do you install it without |
98 | bringing machine down? Suspend to disk, rearrange power cables, |
99 | resume. |
100 | |
101 | You have your server on UPS. Power died, and UPS is indicating 30 |
102 | seconds to failure. What do you do? Suspend to disk. |
103 | |
104 | |
105 | Q: Maybe I'm missing something, but why don't the regular I/O paths work? |
106 | |
107 | A: We do use the regular I/O paths. However we cannot restore the data |
108 | to its original location as we load it. That would create an |
109 | inconsistent kernel state which would certainly result in an oops. |
110 | Instead, we load the image into unused memory and then atomically copy |
111 | it back to it original location. This implies, of course, a maximum |
112 | image size of half the amount of memory. |
113 | |
114 | There are two solutions to this: |
115 | |
116 | * require half of memory to be free during suspend. That way you can |
117 | read "new" data onto free spots, then cli and copy |
118 | |
119 | * assume we had special "polling" ide driver that only uses memory |
120 | between 0-640KB. That way, I'd have to make sure that 0-640KB is free |
121 | during suspending, but otherwise it would work... |
122 | |
123 | suspend2 shares this fundamental limitation, but does not include user |
124 | data and disk caches into "used memory" by saving them in |
125 | advance. That means that the limitation goes away in practice. |
126 | |
127 | Q: Does linux support ACPI S4? |
128 | |
129 | A: Yes. That's what echo platform > /sys/power/disk does. |
130 | |
131 | Q: What is 'suspend2'? |
132 | |
133 | A: suspend2 is 'Software Suspend 2', a forked implementation of |
134 | suspend-to-disk which is available as separate patches for 2.4 and 2.6 |
135 | kernels from swsusp.sourceforge.net. It includes support for SMP, 4GB |
136 | highmem and preemption. It also has a extensible architecture that |
137 | allows for arbitrary transformations on the image (compression, |
138 | encryption) and arbitrary backends for writing the image (eg to swap |
139 | or an NFS share[Work In Progress]). Questions regarding suspend2 |
140 | should be sent to the mailing list available through the suspend2 |
141 | website, and not to the Linux Kernel Mailing List. We are working |
142 | toward merging suspend2 into the mainline kernel. |
143 | |
144 | Q: What is the freezing of tasks and why are we using it? |
145 | |
146 | A: The freezing of tasks is a mechanism by which user space processes and some |
147 | kernel threads are controlled during hibernation or system-wide suspend (on some |
148 | architectures). See freezing-of-tasks.txt for details. |
149 | |
150 | Q: What is the difference between "platform" and "shutdown"? |
151 | |
152 | A: |
153 | |
154 | shutdown: save state in linux, then tell bios to powerdown |
155 | |
156 | platform: save state in linux, then tell bios to powerdown and blink |
157 | "suspended led" |
158 | |
159 | "platform" is actually right thing to do where supported, but |
160 | "shutdown" is most reliable (except on ACPI systems). |
161 | |
162 | Q: I do not understand why you have such strong objections to idea of |
163 | selective suspend. |
164 | |
165 | A: Do selective suspend during runtime power management, that's okay. But |
166 | it's useless for suspend-to-disk. (And I do not see how you could use |
167 | it for suspend-to-ram, I hope you do not want that). |
168 | |
169 | Lets see, so you suggest to |
170 | |
171 | * SUSPEND all but swap device and parents |
172 | * Snapshot |
173 | * Write image to disk |
174 | * SUSPEND swap device and parents |
175 | * Powerdown |
176 | |
177 | Oh no, that does not work, if swap device or its parents uses DMA, |
178 | you've corrupted data. You'd have to do |
179 | |
180 | * SUSPEND all but swap device and parents |
181 | * FREEZE swap device and parents |
182 | * Snapshot |
183 | * UNFREEZE swap device and parents |
184 | * Write |
185 | * SUSPEND swap device and parents |
186 | |
187 | Which means that you still need that FREEZE state, and you get more |
188 | complicated code. (And I have not yet introduce details like system |
189 | devices). |
190 | |
191 | Q: There don't seem to be any generally useful behavioral |
192 | distinctions between SUSPEND and FREEZE. |
193 | |
194 | A: Doing SUSPEND when you are asked to do FREEZE is always correct, |
195 | but it may be unnecessarily slow. If you want your driver to stay simple, |
196 | slowness may not matter to you. It can always be fixed later. |
197 | |
198 | For devices like disk it does matter, you do not want to spindown for |
199 | FREEZE. |
200 | |
201 | Q: After resuming, system is paging heavily, leading to very bad interactivity. |
202 | |
203 | A: Try running |
204 | |
205 | cat `cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u` > /dev/null |
206 | |
207 | after resume. swapoff -a; swapon -a may also be useful. |
208 | |
209 | Q: What happens to devices during swsusp? They seem to be resumed |
210 | during system suspend? |
211 | |
212 | A: That's correct. We need to resume them if we want to write image to |
213 | disk. Whole sequence goes like |
214 | |
215 | Suspend part |
216 | ~~~~~~~~~~~~ |
217 | running system, user asks for suspend-to-disk |
218 | |
219 | user processes are stopped |
220 | |
221 | suspend(PMSG_FREEZE): devices are frozen so that they don't interfere |
222 | with state snapshot |
223 | |
224 | state snapshot: copy of whole used memory is taken with interrupts disabled |
225 | |
226 | resume(): devices are woken up so that we can write image to swap |
227 | |
228 | write image to swap |
229 | |
230 | suspend(PMSG_SUSPEND): suspend devices so that we can power off |
231 | |
232 | turn the power off |
233 | |
234 | Resume part |
235 | ~~~~~~~~~~~ |
236 | (is actually pretty similar) |
237 | |
238 | running system, user asks for suspend-to-disk |
239 | |
240 | user processes are stopped (in common case there are none, but with resume-from-initrd, no one knows) |
241 | |
242 | read image from disk |
243 | |
244 | suspend(PMSG_FREEZE): devices are frozen so that they don't interfere |
245 | with image restoration |
246 | |
247 | image restoration: rewrite memory with image |
248 | |
249 | resume(): devices are woken up so that system can continue |
250 | |
251 | thaw all user processes |
252 | |
253 | Q: What is this 'Encrypt suspend image' for? |
254 | |
255 | A: First of all: it is not a replacement for dm-crypt encrypted swap. |
256 | It cannot protect your computer while it is suspended. Instead it does |
257 | protect from leaking sensitive data after resume from suspend. |
258 | |
259 | Think of the following: you suspend while an application is running |
260 | that keeps sensitive data in memory. The application itself prevents |
261 | the data from being swapped out. Suspend, however, must write these |
262 | data to swap to be able to resume later on. Without suspend encryption |
263 | your sensitive data are then stored in plaintext on disk. This means |
264 | that after resume your sensitive data are accessible to all |
265 | applications having direct access to the swap device which was used |
266 | for suspend. If you don't need swap after resume these data can remain |
267 | on disk virtually forever. Thus it can happen that your system gets |
268 | broken in weeks later and sensitive data which you thought were |
269 | encrypted and protected are retrieved and stolen from the swap device. |
270 | To prevent this situation you should use 'Encrypt suspend image'. |
271 | |
272 | During suspend a temporary key is created and this key is used to |
273 | encrypt the data written to disk. When, during resume, the data was |
274 | read back into memory the temporary key is destroyed which simply |
275 | means that all data written to disk during suspend are then |
276 | inaccessible so they can't be stolen later on. The only thing that |
277 | you must then take care of is that you call 'mkswap' for the swap |
278 | partition used for suspend as early as possible during regular |
279 | boot. This asserts that any temporary key from an oopsed suspend or |
280 | from a failed or aborted resume is erased from the swap device. |
281 | |
282 | As a rule of thumb use encrypted swap to protect your data while your |
283 | system is shut down or suspended. Additionally use the encrypted |
284 | suspend image to prevent sensitive data from being stolen after |
285 | resume. |
286 | |
287 | Q: Can I suspend to a swap file? |
288 | |
289 | A: Generally, yes, you can. However, it requires you to use the "resume=" and |
290 | "resume_offset=" kernel command line parameters, so the resume from a swap file |
291 | cannot be initiated from an initrd or initramfs image. See |
292 | swsusp-and-swap-files.txt for details. |
293 | |
294 | Q: Is there a maximum system RAM size that is supported by swsusp? |
295 | |
296 | A: It should work okay with highmem. |
297 | |
298 | Q: Does swsusp (to disk) use only one swap partition or can it use |
299 | multiple swap partitions (aggregate them into one logical space)? |
300 | |
301 | A: Only one swap partition, sorry. |
302 | |
303 | Q: If my application(s) causes lots of memory & swap space to be used |
304 | (over half of the total system RAM), is it correct that it is likely |
305 | to be useless to try to suspend to disk while that app is running? |
306 | |
307 | A: No, it should work okay, as long as your app does not mlock() |
308 | it. Just prepare big enough swap partition. |
309 | |
310 | Q: What information is useful for debugging suspend-to-disk problems? |
311 | |
312 | A: Well, last messages on the screen are always useful. If something |
313 | is broken, it is usually some kernel driver, therefore trying with as |
314 | little as possible modules loaded helps a lot. I also prefer people to |
315 | suspend from console, preferably without X running. Booting with |
316 | init=/bin/bash, then swapon and starting suspend sequence manually |
317 | usually does the trick. Then it is good idea to try with latest |
318 | vanilla kernel. |
319 | |
320 | Q: How can distributions ship a swsusp-supporting kernel with modular |
321 | disk drivers (especially SATA)? |
322 | |
323 | A: Well, it can be done, load the drivers, then do echo into |
324 | /sys/power/disk/resume file from initrd. Be sure not to mount |
325 | anything, not even read-only mount, or you are going to lose your |
326 | data. |
327 | |
328 | Q: How do I make suspend more verbose? |
329 | |
330 | A: If you want to see any non-error kernel messages on the virtual |
331 | terminal the kernel switches to during suspend, you have to set the |
332 | kernel console loglevel to at least 4 (KERN_WARNING), for example by |
333 | doing |
334 | |
335 | # save the old loglevel |
336 | read LOGLEVEL DUMMY < /proc/sys/kernel/printk |
337 | # set the loglevel so we see the progress bar. |
338 | # if the level is higher than needed, we leave it alone. |
339 | if [ $LOGLEVEL -lt 5 ]; then |
340 | echo 5 > /proc/sys/kernel/printk |
341 | fi |
342 | |
343 | IMG_SZ=0 |
344 | read IMG_SZ < /sys/power/image_size |
345 | echo -n disk > /sys/power/state |
346 | RET=$? |
347 | # |
348 | # the logic here is: |
349 | # if image_size > 0 (without kernel support, IMG_SZ will be zero), |
350 | # then try again with image_size set to zero. |
351 | if [ $RET -ne 0 -a $IMG_SZ -ne 0 ]; then # try again with minimal image size |
352 | echo 0 > /sys/power/image_size |
353 | echo -n disk > /sys/power/state |
354 | RET=$? |
355 | fi |
356 | |
357 | # restore previous loglevel |
358 | echo $LOGLEVEL > /proc/sys/kernel/printk |
359 | exit $RET |
360 | |
361 | Q: Is this true that if I have a mounted filesystem on a USB device and |
362 | I suspend to disk, I can lose data unless the filesystem has been mounted |
363 | with "sync"? |
364 | |
365 | A: That's right ... if you disconnect that device, you may lose data. |
366 | In fact, even with "-o sync" you can lose data if your programs have |
367 | information in buffers they haven't written out to a disk you disconnect, |
368 | or if you disconnect before the device finished saving data you wrote. |
369 | |
370 | Software suspend normally powers down USB controllers, which is equivalent |
371 | to disconnecting all USB devices attached to your system. |
372 | |
373 | Your system might well support low-power modes for its USB controllers |
374 | while the system is asleep, maintaining the connection, using true sleep |
375 | modes like "suspend-to-RAM" or "standby". (Don't write "disk" to the |
376 | /sys/power/state file; write "standby" or "mem".) We've not seen any |
377 | hardware that can use these modes through software suspend, although in |
378 | theory some systems might support "platform" modes that won't break the |
379 | USB connections. |
380 | |
381 | Remember that it's always a bad idea to unplug a disk drive containing a |
382 | mounted filesystem. That's true even when your system is asleep! The |
383 | safest thing is to unmount all filesystems on removable media (such USB, |
384 | Firewire, CompactFlash, MMC, external SATA, or even IDE hotplug bays) |
385 | before suspending; then remount them after resuming. |
386 | |
387 | There is a work-around for this problem. For more information, see |
388 | Documentation/usb/persist.txt. |
389 | |
390 | Q: Can I suspend-to-disk using a swap partition under LVM? |
391 | |
392 | A: No. You can suspend successfully, but you'll not be able to |
393 | resume. uswsusp should be able to work with LVM. See suspend.sf.net. |
394 | |
395 | Q: I upgraded the kernel from 2.6.15 to 2.6.16. Both kernels were |
396 | compiled with the similar configuration files. Anyway I found that |
397 | suspend to disk (and resume) is much slower on 2.6.16 compared to |
398 | 2.6.15. Any idea for why that might happen or how can I speed it up? |
399 | |
400 | A: This is because the size of the suspend image is now greater than |
401 | for 2.6.15 (by saving more data we can get more responsive system |
402 | after resume). |
403 | |
404 | There's the /sys/power/image_size knob that controls the size of the |
405 | image. If you set it to 0 (eg. by echo 0 > /sys/power/image_size as |
406 | root), the 2.6.15 behavior should be restored. If it is still too |
407 | slow, take a look at suspend.sf.net -- userland suspend is faster and |
408 | supports LZF compression to speed it up further. |
409 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9