[PATCH] swsusp: documentation updates
Update suspend-to-RAM documentation with new machines, and makes message when processes can't be stopped little clearer. (In one case, waiting longer actually did help). From: "Rafael J. Wysocki" <rjw@sisk.pl> Warn in the documentation that data may be lost if there are some filesystems mounted from USB devices before suspend. [Thanks to Alan Stern for providing the answer to the question in the Q:-A: part.] Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>hifive-unleashed-5.1
Pavel Machek
Linus Torvalds
parent
74c7e2efbe
commit
543cc27d09
|
|
@ -17,6 +17,11 @@ Some warnings, first.
|
|||
* but it will probably only crash.
|
||||
*
|
||||
* (*) suspend/resume support is needed to make it safe.
|
||||
*
|
||||
* If you have any filesystems on USB devices mounted before suspend,
|
||||
* they won't be accessible after resume and you may lose data, as though
|
||||
* you have unplugged the USB devices with mounted filesystems on them
|
||||
* (see the FAQ below for details).
|
||||
|
||||
You need to append resume=/dev/your_swap_partition to kernel command
|
||||
line. Then you suspend by
|
||||
|
|
@ -27,19 +32,18 @@ echo shutdown > /sys/power/disk; echo disk > /sys/power/state
|
|||
|
||||
echo platform > /sys/power/disk; echo disk > /sys/power/state
|
||||
|
||||
. If you have SATA disks, you'll need recent kernels with SATA suspend
|
||||
support. For suspend and resume to work, make sure your disk drivers
|
||||
are built into kernel -- not modules. [There's way to make
|
||||
suspend/resume with modular disk drivers, see FAQ, but you probably
|
||||
should not do that.]
|
||||
|
||||
If you want to limit the suspend image size to N bytes, do
|
||||
|
||||
echo N > /sys/power/image_size
|
||||
|
||||
before suspend (it is limited to 500 MB by default).
|
||||
|
||||
Encrypted suspend image:
|
||||
------------------------
|
||||
If you want to store your suspend image encrypted with a temporary
|
||||
key to prevent data gathering after resume you must compile
|
||||
crypto and the aes algorithm into the kernel - modules won't work
|
||||
as they cannot be loaded at resume time.
|
||||
|
||||
|
||||
Article about goals and implementation of Software Suspend for Linux
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -333,4 +337,37 @@ init=/bin/bash, then swapon and starting suspend sequence manually
|
|||
usually does the trick. Then it is good idea to try with latest
|
||||
vanilla kernel.
|
||||
|
||||
Q: How can distributions ship a swsusp-supporting kernel with modular
|
||||
disk drivers (especially SATA)?
|
||||
|
||||
A: Well, it can be done, load the drivers, then do echo into
|
||||
/sys/power/disk/resume file from initrd. Be sure not to mount
|
||||
anything, not even read-only mount, or you are going to lose your
|
||||
data.
|
||||
|
||||
Q: How do I make suspend more verbose?
|
||||
|
||||
A: If you want to see any non-error kernel messages on the virtual
|
||||
terminal the kernel switches to during suspend, you have to set the
|
||||
kernel console loglevel to at least 5, for example by doing
|
||||
|
||||
echo 5 > /proc/sys/kernel/printk
|
||||
|
||||
Q: Is this true that if I have a mounted filesystem on a USB device and
|
||||
I suspend to disk, I can lose data unless the filesystem has been mounted
|
||||
with "sync"?
|
||||
|
||||
A: That's right. It depends on your hardware, and it could be true even for
|
||||
suspend-to-RAM. In fact, even with "-o sync" you can lose data if your
|
||||
programs have information in buffers they haven't written out to disk.
|
||||
|
||||
If you're lucky, your hardware will support low-power modes for USB
|
||||
controllers while the system is asleep. Lots of hardware doesn't,
|
||||
however. Shutting off the power to a USB controller is equivalent to
|
||||
unplugging all the attached devices.
|
||||
|
||||
Remember that it's always a bad idea to unplug a disk drive containing a
|
||||
mounted filesystem. With USB that's true even when your system is asleep!
|
||||
The safest thing is to unmount all USB-based filesystems before suspending
|
||||
and remount them after resuming.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
Video issues with S3 resume
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
2003-2005, Pavel Machek
|
||||
2003-2006, Pavel Machek
|
||||
|
||||
During S3 resume, hardware needs to be reinitialized. For most
|
||||
devices, this is easy, and kernel driver knows how to do
|
||||
|
|
@ -15,6 +15,27 @@ run normally so video card is normally initialized. It should not be
|
|||
problem for S1 standby, because hardware should retain its state over
|
||||
that.
|
||||
|
||||
We either have to run video BIOS during early resume, or interpret it
|
||||
using vbetool later, or maybe nothing is neccessary on particular
|
||||
system because video state is preserved. Unfortunately different
|
||||
methods work on different systems, and no known method suits all of
|
||||
them.
|
||||
|
||||
Userland application called s2ram has been developed; it contains long
|
||||
whitelist of systems, and automatically selects working method for a
|
||||
given system. It can be downloaded from CVS at
|
||||
www.sf.net/projects/suspend . If you get a system that is not in the
|
||||
whitelist, please try to find a working solution, and submit whitelist
|
||||
entry so that work does not need to be repeated.
|
||||
|
||||
Currently, VBE_SAVE method (6 below) works on most
|
||||
systems. Unfortunately, vbetool only runs after userland is resumed,
|
||||
so it makes debugging of early resume problems
|
||||
hard/impossible. Methods that do not rely on userland are preferable.
|
||||
|
||||
Details
|
||||
~~~~~~~
|
||||
|
||||
There are a few types of systems where video works after S3 resume:
|
||||
|
||||
(1) systems where video state is preserved over S3.
|
||||
|
|
@ -104,6 +125,7 @@ HP NX7000 ??? (*)
|
|||
HP Pavilion ZD7000 vbetool post needed, need open-source nv driver for X
|
||||
HP Omnibook XE3 athlon version none (1)
|
||||
HP Omnibook XE3GC none (1), video is S3 Savage/IX-MV
|
||||
HP Omnibook 5150 none (1), (S1 also works OK)
|
||||
IBM TP T20, model 2647-44G none (1), video is S3 Inc. 86C270-294 Savage/IX-MV, vesafb gets "interesting" but X work.
|
||||
IBM TP A31 / Type 2652-M5G s3_mode (3) [works ok with BIOS 1.04 2002-08-23, but not at all with BIOS 1.11 2004-11-05 :-(]
|
||||
IBM TP R32 / Type 2658-MMG none (1)
|
||||
|
|
@ -120,18 +142,24 @@ IBM ThinkPad T42p (2373-GTG) s3_bios (2)
|
|||
IBM TP X20 ??? (*)
|
||||
IBM TP X30 s3_bios (2)
|
||||
IBM TP X31 / Type 2672-XXH none (1), use radeontool (http://fdd.com/software/radeon/) to turn off backlight.
|
||||
IBM TP X32 none (1), but backlight is on and video is trashed after long suspend
|
||||
IBM TP X32 none (1), but backlight is on and video is trashed after long suspend. s3_bios,s3_mode (4) works too. Perhaps that gets better results?
|
||||
IBM Thinkpad X40 Type 2371-7JG s3_bios,s3_mode (4)
|
||||
IBM TP 600e none(1), but a switch to console and back to X is needed
|
||||
Medion MD4220 ??? (*)
|
||||
Samsung P35 vbetool needed (6)
|
||||
Sharp PC-AR10 (ATI rage) none (1)
|
||||
Sharp PC-AR10 (ATI rage) none (1), backlight does not switch off
|
||||
Sony Vaio PCG-C1VRX/K s3_bios (2)
|
||||
Sony Vaio PCG-F403 ??? (*)
|
||||
Sony Vaio PCG-GRT995MP none (1), works with 'nv' X driver
|
||||
Sony Vaio PCG-GR7/K none (1), but needs radeonfb, use radeontool (http://fdd.com/software/radeon/) to turn off backlight.
|
||||
Sony Vaio PCG-N505SN ??? (*)
|
||||
Sony Vaio vgn-s260 X or boot-radeon can init it (5)
|
||||
Sony Vaio vgn-S580BH vga=normal, but suspend from X. Console will be blank unless you return to X.
|
||||
Sony Vaio vgn-FS115B s3_bios (2),s3_mode (4)
|
||||
Toshiba Libretto L5 none (1)
|
||||
Toshiba Satellite 4030CDT s3_mode (3)
|
||||
Toshiba Satellite 4080XCDT s3_mode (3)
|
||||
Toshiba Portege 3020CT s3_mode (3)
|
||||
Toshiba Satellite 4030CDT s3_mode (3) (S1 also works OK)
|
||||
Toshiba Satellite 4080XCDT s3_mode (3) (S1 also works OK)
|
||||
Toshiba Satellite 4090XCDT ??? (*)
|
||||
Toshiba Satellite P10-554 s3_bios,s3_mode (4)(****)
|
||||
Toshiba M30 (2) xor X with nvidia driver using internal AGP
|
||||
|
|
@ -151,39 +179,3 @@ Asus A7V8X nVidia RIVA TNT2 model 64 s3_bios,s3_mode (4)
|
|||
(***) To be tested with a newer kernel.
|
||||
|
||||
(****) Not with SMP kernel, UP only.
|
||||
|
||||
VBEtool details
|
||||
~~~~~~~~~~~~~~~
|
||||
(with thanks to Carl-Daniel Hailfinger)
|
||||
|
||||
First, boot into X and run the following script ONCE:
|
||||
#!/bin/bash
|
||||
statedir=/root/s3/state
|
||||
mkdir -p $statedir
|
||||
chvt 2
|
||||
sleep 1
|
||||
vbetool vbestate save >$statedir/vbe
|
||||
|
||||
|
||||
To suspend and resume properly, call the following script as root:
|
||||
#!/bin/bash
|
||||
statedir=/root/s3/state
|
||||
curcons=`fgconsole`
|
||||
fuser /dev/tty$curcons 2>/dev/null|xargs ps -o comm= -p|grep -q X && chvt 2
|
||||
cat /dev/vcsa >$statedir/vcsa
|
||||
sync
|
||||
echo 3 >/proc/acpi/sleep
|
||||
sync
|
||||
vbetool post
|
||||
vbetool vbestate restore <$statedir/vbe
|
||||
cat $statedir/vcsa >/dev/vcsa
|
||||
rckbd restart
|
||||
chvt $[curcons%6+1]
|
||||
chvt $curcons
|
||||
|
||||
|
||||
Unless you change your graphics card or other hardware configuration,
|
||||
the state once saved will be OK for every resume afterwards.
|
||||
NOTE: The "rckbd restart" command may be different for your
|
||||
distribution. Simply replace it with the command you would use to
|
||||
set the fonts on screen.
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ int freeze_processes(void)
|
|||
yield(); /* Yield is okay here */
|
||||
if (todo && time_after(jiffies, start_time + TIMEOUT)) {
|
||||
printk( "\n" );
|
||||
printk(KERN_ERR " stopping tasks failed (%d tasks remaining)\n", todo );
|
||||
printk(KERN_ERR " stopping tasks timed out (%d tasks remaining)\n", todo );
|
||||
break;
|
||||
}
|
||||
} while(todo);
|
||||
|
|
|
|||
Loading…
Reference in New Issue