Suspend 2 merge: 25/51: Documentation

[Nigel Cunningham]

Here is the kernel tree documentation. I have a word document that I'm
also working on, which will provide detail not given here, including an
explanation of the API for people who want to write new extensions.

diff -ruN 810-documentation-old/Documentation/kernel-parameters.txt 810-documentation-new/Documentation/kernel-parameters.txt
--- 810-documentation-old/Documentation/kernel-parameters.txt	2004-11-03 21:55:04.000000000 +1100
+++ 810-documentation-new/Documentation/kernel-parameters.txt	2004-11-04 16:27:40.000000000 +1100
@@ -804,6 +804,8 @@
 
 	noresume	[SWSUSP] Disables resume and restore original swap space.
  
+	noresume2	[SWSUSP2] Disables resuming and restores original swap signature.
+ 
 	no-scroll	[VGA] Disables scrollback.
 			This is required for the Braillex ib80-piezo Braille
 			reader made by F.H. Papenmeier (Germany).
@@ -1011,7 +1013,12 @@
 
 	reserve=	[KNL,BUGS] Force the kernel to ignore some iomem area
 
-	resume=		[SWSUSP] Specify the partition device for software suspension
+	resume=		[SWSUSP] Specify the partition device for software suspension.
+
+	resume2=	[SWSUSP2] Specify the storage device for software suspend.
+			Format: <writer>:<writer-parameters>.
+			See Documentation/power/swsusp2.txt for details of the formats
+			for available image writers.
 
 	rhash_entries=	[KNL,NET]
 			Set number of hash buckets for route cache
diff -ruN 810-documentation-old/Documentation/power/suspend2.txt 810-documentation-new/Documentation/power/suspend2.txt
--- 810-documentation-old/Documentation/power/suspend2.txt	1970-01-01 10:00:00.000000000 +1000
+++ 810-documentation-new/Documentation/power/suspend2.txt	2004-11-04 16:27:40.000000000 +1100
@@ -0,0 +1,506 @@
+		--- Software Suspend for Linux, version 2.0 ---
+
+1.  What is it?
+2.  Why would you want it?
+3.  What do you need to use it?
+4.  How do you use it?
+5.  What do all those entries in /proc/software_suspend do?
+6.  How do you get support?
+7.  I think I've found a bug. What should I do?
+8.  When will XXX be supported?
+9.  How does it work?
+10. Who wrote Software Suspend?
+
+1. What is it?
+
+   Imagine you're sitting at your computer, working away. For some reason, you
+   need to turn off your computer for a while - perhaps it's time to go home
+   for the day. When you come back to your computer next, you're going to want
+   to carry on where you left off. Now imagine that you could push a button and
+   have your computer store the contents of its memory to disk and power down.
+   Then, when you next start up your computer, it loads that image back into
+   memory and you can carry on from where you were, just as if you'd never
+   turned the computer off. Far less time to start up, no reopening
+   applications and finding what directory you put that file in yesterday.
+   That's what Software Suspend does.
+
+2. Why would you want it?
+
+   Why wouldn't you want it?
+   
+   Being able to save the state of your system and quickly restore it improves
+   your productivity - you get a useful system in far less time than through
+   the normal boot process.
+   
+3. What do you need to use it?
+
+   a. Kernel Support.
+   
+   Software Suspend is part of the Linux Kernel. This version is not part of Linus's
+   2.6 tree at the moment, so you will need to download the kernel source and
+   apply the latest patch. Having done that, enable the appropriate options in
+   make [menu|x]config (under General Setup), compile and install your kernel.
+   Software Suspend works with SMP, Highmem, preemption, x86-32, PPC and mac.
+   x86-64 support is coming.
+
+   Software Suspend patches are available from http://softwaresuspend.berlios.de.
+
+   You may also want to apply the optional patches. At the time of writing,
+   option patches are available to support Bootsplash (www.bootsplash.org, for
+   an even nicer display during suspend), Win4Lin. The Win4Lin option patch (only
+   needed for 2.4) provides support for Win4Lin.
+   
+   Option patches should be applied after the main patch and after Win4Lin
+   or Bootsplash.
+   
+   As of version 2.0.0.102, suspend can be built as modules. To use this
+   configuration, you need to have initrd support, because resuming needs
+   to occur before any filesystems that were mounted when you suspended
+   are remounted. For details on setting up suspend-as-modules, please
+   read the FAQs on suspend's web site.
+
+   b. Swapspace.
+
+   Software Suspend can store the suspend image in your swap partition,
+   a swap file or a combination thereof. Whichever combination you choose, you
+   will probably want to create enough swap space to store the largest image
+   you could have, plus the space you'd normally use for swap. A good rule of
+   thumb would be to calculate the amount of swap you'd want without using
+   Software Suspend, and then add the amount of memory you have. This swap
+   space can be arranged in any way you'd like. It can be in one partition or
+   file, or spread over a number. The only requirement is that they be active
+   when you start a suspend cycle.
+   
+   There is one exception to this requirement. Software Suspend has
+   the ability to turn on one swap file or partition at the start of
+   suspending and turn it back off at the end. If you want to ensure you have
+   enough memory to store a image when your memory is fully used, you might 
+   want to make one swap partition/file for 'normal' use, and another for
+   Software Suspend to activate & deactivate automatically. (Further details
+   below).
+
+   c. Bootloader configuration.
+   
+   Using Software Suspend also requires that you add an extra parameter to 
+   your lilo.conf or equivalent. Here's an example for a swap partition:
+
+   append="resume2=/dev/hda1"
+
+   This would tell Software Suspend that /dev/hda1 is a swap partition you 
+   have. Software Suspend will use the swap signature of this partition as a
+   pointer to your data when you suspend. This means that (in this example)
+   /dev/hda1 doesn't need to be _the_ swap partition where all of your data
+   is actually stored. It just needs to be a swap partition that has a
+   valid signature.
+
+   You don't need to have a swap partition for this purpose. Software Suspend
+   can also use a swap file, but usage is a little more complex. Having made
+   your swap file, turn it on and do 
+
+   cat /proc/software_suspend/header_locations
+
+   (this assumes you've already compiled your kernel with Software Suspend
+   support and booted it). The results of the cat command will tell you
+   what you need to put in lilo.conf:
+
+   For swap partitions like /dev/hda1, simply use resume2=/dev/hda1.
+   For swapfile `swapfile`, use resume2=/dev/hda2:0x242d@4096.
+
+   If the swapfile changes for any reason (it is moved to a different
+   location, it is deleted and recreated, or the filesystem is
+   defragmented) then you will have to check
+   /proc/software_suspend/header_locations for a new resume_block value.
+
+   Once you've compiled and installed the kernel, adjusted your lilo.conf
+   and rerun lilo, you should only need to reboot for the most basic part
+   of Software Suspend to be ready.
+
+   d. A suspend script.
+
+   Since the driver model in 2.6 kernels is still being developed, you may need
+   to do more, however. Users of Software Suspend usually start the process 
+   via a script which prepares for the suspend, tells the kernel to do its
+   stuff and then restore things afterwards. This script might involve:
+
+   - Switching to a text console and back if X doesn't like the video card
+     status on resume.
+   - Running /sbin/hwclock [--directisa] to update the clock on resume
+   - Un/reloading PCMCIA support since it doesn't play well with suspend.
+  
+   Note that you might not be able to unload some drivers if there are 
+   processes using them. You might have to kill off processes that hold
+   devices open. Hint: if your X server accesses an USB mouse, doing a
+   'chvt' to a text console releases the device and you can unload the
+   module.
+
+   Check out the latest script (available on Berlios).
+   
+4. How do you use it?
+
+   Once your script is properly set up, you should just be able to start it
+   and everything should go like clockwork. Of course things aren't always
+   that easy out of the box.
+
+   Check out (in the kernel source tree) include/linux/suspend-debug for
+   settings you can use to get detailed information about what suspend is doing.
+   /proc/sys/kernel/swsusp and the kernel parameters suspend_act, suspend_dbg
+   and suspend_lvl allow you to set the action and debugging parameters prior
+   to starting a suspend and/or at the lilo prompt before resuming. There is
+   also a nice little program that should be available from Berlios which
+   makes it easier to turn these debugging settings on and off. Note that to
+   get any debugging output, you need to enable it when compiling the kernel.
+
+   A neat feature of Software Suspend is that you can press Escape at any time
+   during suspending, and the process will be aborted.
+   
+   Due to the way suspend works, this means you'll have your system back and
+   perfectly usable almost instantly. The only exception is when it's at
+   the very end of writing the image. Then it will need to reload a small
+   (usually 4-50MBs) portion first.
+
+   If you run into problems with resuming, adding the "noresume2" option to
+   the kernel command line will let you skip the resume step and
+   (hopefully) recover your system.
+
+5. What do all those entries in /proc/software_suspend do?
+
+   /proc/software_suspend is the directory which contains files you can use to
+   tune and configure Software Suspend to your liking. The exact contents of
+   the directory will depend upon the version of Software Suspend you're
+   running, the options you selected at compile time and which modules you have
+   inserted at the moment (where appropriate). In the following
+   descriptions, names in brackets refer to compile time options and modules
+   that control whether the file exists. (Note that they're all dependant upon
+   you having selected CONFIG_SOFTWARE_SUSPEND2 in the first place!)
+
+   Since the values of these settings can open potential security risks, they
+   are usually accessible only to the root user. You can, however, enable a
+   compile time option which makes all of these files world-accessible. This
+   should only be done if you trust everyone with shell access to this
+   computer!
+  
+   - activate:
+
+   When anything is written to this file suspend will be activated and suspend
+   the system. The value is completely ignored. It is just the fact that you
+   write to the file that initiates the suspend.
+
+   When accessed from an initrd, the software instead checks whether it needs
+   to initiate a resume. If it doesn't, the echo returns almost immediately.
+   If a resume is needed, the echo never returns.
+
+   - async_io_limit: (module suspend_block_io)
+
+   This value is the limit on the number of pages Software Suspend will submit
+   for reading or writing at once. The ideal value depends upon the speed of
+   your hard disks, but the default (and maximum) of 256 should be fine.
+
+   - debug_info:
+  
+   This file returns information about your configuration that may be helpful
+   in diagnosing problems with suspending.
+
+   - debug_sections (CONFIG_SOFTWARE_SUSPEND_DEBUG, module suspend_core):
+
+   This value, together with the console log level, controls what debugging
+   information is displayed. The console log level determines the level of
+   detail, and this value determines what detail is displayed. This value is
+   a bit vector, and the meaning of the bits can be found in the kernel tree
+   in include/linux/suspend-debug.h. It can be over-ridden using the kernel's
+   command line option suspend_dbg.
+
+   - default_console_level (CONFIG_SOFTWARE_SUSPEND_DEBUG, module suspend_core):
+
+   This determines the value of the console log level at the start of a
+   suspend cycle. If debugging is compiled in, the console log level can be
+   changed during a cycle by pressing the digit keys. Meanings are:
+
+   0: Nice display.
+   1: Nice display plus numerical progress.
+   2: Errors only.
+   3: Low level debugging info.
+   4: Medium level debugging info.
+   5: High level debugging info.
+   6: Verbose debugging info.
+
+   This value can be over-ridden using the kernel command line option 
+   suspend_lvl.
+
+   - disable_gzip_compression (CONFIG_SOFTWARE_SUSPEND_GZIP_COMPRESSION,
+	module suspend_gzip):
+
+   If gzip compression support is compiled in, this option can be used to 
+   disable this plugin.
+
+   - disable_lzf_compression (CONFIG_SOFTWARE_SUSPEND_LZF_COMPRESSION,
+	modules suspend_lzf):
+
+   If lzf compression support is compiled in, this option can be used to 
+   disable this plugin.
+
+   - enable_escape (module suspend_core):
+
+   Setting this to "1" will enable you abort a suspend by
+   pressing escape, "0" (default) disables this feature. Note that enabling
+   this option means that you cannot initiate a suspend and then walk away
+   from your computer, expecting it to be secure. With feature disabled,
+   you can validly have this expectation once Suspend begins to write the
+   image to disk. (Prior to this point, it is possible that Suspend might
+   about because of failure to freeze all processes or because constraints
+   on its ability to save the image are not met).
+
+   - expected_gzip_compression (CONFIG_SOFTWARE_SUSPEND_GZIP_COMPRESSION,
+	module suspend_gzip):
+   - expected_lzf_compression (CONFIG_SOFTWARE_SUSPEND_LZF_COMPRESSION,
+	module suspend_lzf):
+
+   These values allow you to set an expected compression ratio, which Software
+   Suspend will use in calculating whether it meets constraints on the image
+   size. If this expected compression ratio is not attained, the suspend will
+   abort, so it is wise to allow some spare. You can see what compression
+   ratio is achieved in the logs after suspending.
+
+   Note that the values are cumulative. If you compile in both gzip and lzf
+   compression, have both enabled, and set both expected compression ratios
+   to 20, Suspend will expect that the storage required  will be at most 
+   .8 * .8 = 64% of the number of pages to be written.
+
+   - header_locations:
+
+   This option tells you the resume= options to use for swap devices you
+   currently have activated. It is particularly useful when you only want to
+   use a swap file to store your image. See above for further details.
+
+   - image_size_limit:
+
+   The maximum size of suspend image written to disk, measured in megabytes
+   (1024*1024).
+
+   - interface_version:
+
+   The value returned by this file can be used by scripts and configuration
+   tools to determine what entries should be looked for. The value is
+   incremented whenever an entry in /proc/software_suspend is obsoleted or 
+   added.
+
+   - last_result:
+
+   The result of the last suspend, as defined in
+   include/linux/suspend-debug.h with the values SUSPEND_ABORTED to
+   SUSPEND_KEPT_IMAGE. This is a bitmask.
+
+   - log_everything (CONFIG_SOFTWARE_SUSPEND_DEBUG):
+
+   Setting this option results in all messages printed being logged. Normally,
+   only a subset are logged, so as to not slow the process and not clutter the
+   logs. Useful for debugging. It can be toggled during a cycle by pressing
+   'L'.
+
+   - no_output:
+
+   Setting this to "1" disables all output from suspend. It may be useful if a
+   distribution wants to implement a static display while suspending.
+
+   - pause_between_steps (CONFIG_SOFTWARE_SUSPEND_DEBUG):
+
+   This option is used during debugging, to make Software Suspend pause between
+   each step of the process. It is ignored when the nice display is on.
+
+   - progressbar_granularity_limit (CONFIG_FBCON_SPLASHSCREEN):
+
+   This option can be used to limit the granularity of the progress bar
+   displayed with a bootsplash screen. The value is the maximum number of
+   steps. That is, 10 will make the progress bar jump in 10% increments.
+
+   - reboot (CONFIG_SOFTWARE_SUSPEND_DEBUG):
+
+   This option causes Software Suspend to reboot rather than powering down
+   at the end of saving an image. It can be toggled during a cycle by pressing
+   'R'.
+
+   - slow:
+
+   This option inserts a couple of one+ second delays in the code. It should
+   not be needed, and may disappear in a future version.
+
+   - swapfile:
+
+   This entry is used to specify the swapfile or partition that
+   Software Suspend will attempt to swapon/swapoff automatically. Thus, if
+   I normally use /dev/hda1 for swap, and want to use /dev/hda2 for specifically
+   for my suspend image, I would
+  
+   echo /dev/hda2 > /proc/software_suspend/swapfile
+
+   /dev/hda2 would then be automatically swapon'd and swapoff'd. Note that the
+   swapon and swapoff occur while other processes are frozen (including kswapd)
+   so this swap file will not be used up when attempting to free memory. The
+   parition/file is also given the highest priority, so other swapfiles/partitions
+   will only be used to save the image when this one is filled.
+
+   The value of this file is used by header_locations along with any currently
+   activated swapfiles/partitions.
+
+   - version:
+  
+   The version of suspend you have compiled into the currently running kernel.
+
+6. How do you get support?
+
+   Glad you asked. Software Suspend is being actively maintained and supported,
+   both by Nigel (the guy doing most of the coding at the moment) and its
+   users. You can find the mailing list via the Sourceforge project page.
+
+7. I think I've found a bug. What should I do?
+
+   If you're seeing Software Suspend hang at some point, and especially if
+   lights are flashing on your keyboard, you should compile in debugging 
+   support and try...
+   
+   echo 1 > /proc/software_suspend/debug_sections
+   echo 3 > /proc/software_suspend/default_console_level
+   echo > /proc/software_suspend/activate
+
+   You should then see low level debugging information and eventually an
+   oops.
+
+   Good information on how to provide us with useful information from an
+   oops is found in the file REPORTING-BUGS, in the top level directory
+   of the kernel tree. If you get an oops, please especially note the
+   information about running what is printed on the screen through ksymoops.
+   The raw information is useless.
+
+   You might also read the FAQ and HOWTO on the web site for known issues,
+   and subscribe to the mailing list.
+
+   Beginning with 1.1rc10, you should include the contents of 
+   /proc/software_suspend/debug_info in your report. Prior to this version,
+   similar information is written to /var/log/messages at the end of a
+   successful resume and should be sent. It is also a good idea to check
+   /var/log/messages for relevant information as well. Information from the
+   unloading and reloading of drivers and modules  prior to and after 
+   suspending is sometimes helpful.
+
+8. When will XXX be supported?
+
+   Software Suspend currently lacks support for x86-64..
+
+   Patches for the other items (and anything that's been missed) are welcome. 
+   Please send to the list.
+
+   Because Nigel's main task is definitely not Software Suspend and he doesn't
+   have the hardware, he will be unlikely to develop support for any of these
+   in the near future. His development work to date has been driven by the
+   desire to be a user of a more feature complete Software Suspend.
+
+9. How does it work?
+
+   Software Suspend does its work in a number of steps.
+
+   a. Freezing system activity.
+
+   The first main stage in suspending is to stop all other activity. This is
+   achieved in stages. First, we stop tasks from submitting new I/O using hooks
+   in the system calls for reading, writing and at a number of other places as
+   well as at the kernel threads that start I/O. If any tasks are syncing,
+   we wait for them to complete. We then do our own sync, just in case no
+   syncs were running. Next, we stop all the others tasks. Some are signalled
+   and put in a 'refrigerator'. Others are simply not scheduled again until we
+   decide to wake them up.
+
+   b. Eating memory.
+
+   For a successful suspend, you need to have enough disk space to store the
+   image and enough memory for the various limitations of Software Suspend's
+   algorithm. You can also specify a maximum image size. In order to attain
+   to those constraints, Software Suspend may 'eat' memory. If, after freezing
+   processes, the constraints aren't met, Software Suspend will thaw all the
+   other processes and begin to eat memory until its calculations indicate
+   the constraints are met. It will then freeze processes again and recheck
+   its calculations.
+
+   c. Suspending drivers and storing processor context.
+
+   Software Suspend then calls the power management functions to notify
+   drivers of the suspend, and saves the processor state.
+
+   d. Storage of meta data and image.
+
+   Next, Software Suspend allocates the swap pages that will be used to save
+   the image and stores their locations, along with the locations of the pages
+   to be saved in what we call pagesets or pagedirs. Software Suspend stores
+   data in two pagesets. Pageset 2 contains pages on the active and inactive
+   lists; essentially the page cache. Pageset 1 contains all other pages,
+   including the kernel. We use two pagesets for one important reason: We
+   need to make an atomic copy of the kernel to ensure consistency of the
+   image. Without a second pagedir, that would limit us to an image that was
+   at most half the amount of memory available. Using two pagesets allows us
+   to store a full image. Since pageset 2 pages won't be needed in saving
+   pageset 1, we first save pageset 2 pages. We can then make our atomic copy
+   of the remaining pages using both pageset 2 pages and any other pages that
+   are free. While saving both pagesets, we are careful not to corrupt the
+   image. We immediately shoot down pages that are added to the page cache,
+   and we allocate a special memory pool of extra pages that can be used by
+   during suspending. All of the pages in this pool are saved along with the
+   rest of the pageset 1 pages, even if they're not used. This saves us having
+   to worry about the image becoming inconsistent while we're saving it.
+
+   e. Save a second copy of the pagedirs.
+
+   To reload pagedir 1 at resume time, we need to know where the data is
+   stored. This requires the saving of a second copy of the pagedirs.
+
+   f. Save the suspend header.
+
+   Nearly there! We save our settings and other parameters needed for
+   reloading pagedir 1 in a 'suspend header' this is a single swap page.
+
+   g. Set the swap header.
+
+   Finally, we edit the swap header for our resume= swap file/partition. The
+   swap signature is changed to record what kind of header it originally was
+   (swapspace 1 or 2) and the bdev and first block and block size details of
+   the suspend header.
+
+   h. Power down.
+
+   Or reboot if we're debugging and the appropriate option is selected.
+
+   Whew!
+
+   Reloading the image.
+   --------------------
+
+   Reloading the image is essentially the reverse of all the above. We load
+   our copy of pagedir 1, being careful to choose locations that aren't going
+   to be overwritten as we copy it back (We start very early in the boot
+   process, so there are no other processes to quiesce here). We then copy
+   pagedir 1 back to its original location in memory and restore the process
+   context. We are now running with the original kernel. Next, we reload the
+   pageset 2 pages, free the memory and swap used by Software Suspend, restore
+   the pagedir header and restart processes. Sounds easy in comparison to
+   suspending, doesn't it!
+
+   There is of course more to Software Suspend than this, but this explanation
+   should be a good start. If there's interest, I'll write further
+   documentation on range pages and the low level I/O.
+
+10. Who wrote Software Suspend?
+
+   (Answer based on the writings of Florent Chabaud, credits in files and
+   Nigel's limited knowledge; apologies to anyone missed out!)
+
+   The main developers of Software Suspend have been...
+
+   Gabor Kuti
+   Pavel Machek
+   Florent Chabaud
+   Nigel Cunningham
+
+   They have been aided in their efforts by a host of hundreds, if not thousands
+   of testers and people who have submitted bug fixes & suggestions. Of special
+   note are the efforts of Michael Frank, who had his computers repetitively
+   suspend and resume for literally tens of thousands of cycles and developed
+   scripts to stress the system and test Software Suspend far beyond the point
+   most of us (Nigel included!) would consider testing. His efforts have
+   contributed as much to Software Suspend as any of the names above.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/