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