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