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