[Yaird-devel] Bug#329319: yaird: swsusp not all that hard

Mon Dec 12 22:59:05 UTC 2005

On Fri, Dec 09, 2005 at 11:12:05AM -0500, C. Scott Ananian wrote:
> Package: yaird
> Version: 0.0.11-12
> Followup-For: Bug #329319
> 
> It's not all that hard to prevent log replay: just don't mount the file
> systems!  Resume should happen *after* the modules required to access the
> swap partition are installed (ide, piix, etc), but *before* the root
> partition is mounted.  Mounting read-only is bad, too, because that causes
> journal replay.  Just load the modules and transfer to the resume code,
> which will take care of the rest.
> 
> The more interesting question is: how do I tell which partition I need
> to resume from?  yaird needs to know this so that it can make sure the
> right modules are loaded (otherwise resume will complain "device not found").
> swsusp uses "resume=/dev/hda#" and suspend2 uses "resume2=swap:/dev/hda#"
> on the command-line, but it would really be preferable to use a mount option
> in /etc/fstab instead.  After all, yaird is good at figuring out things
> like that; grub/lilo are not.
> 
> For standard swsusp, 
>    cat /sys/block/hda/hda5/dev > /sys/power/resume
> (for example) at initramfs-time will both initialize the 'resume=' option
> (avoiding the need for a command-line argument) and also perform the
> resume if appropriate.  I don't know if suspend2 has a similar mechanism.
> 
> So it should be pretty straight-forward for yaird to:
>  1) look in /etc/fstab for a swap partition with the 'resume' option.
>  2) add a target just before filesystem mount (MKSWAP or some such)
>     which loads the modules needed to access that partition
>  3) if there isn't a "noresume" or "noresume2" option on the command-line,
>     performs the swsusp or suspend2-appropriate resume action.
>     (or both, since only one or the other will actually work).
> 
> Everything else should be handled by the resume.
>  --scott

Hi,

Just a quick thank-you note for your input & patch; your stuff really helps
in getting a clear picture of what we need here.

The issue of where to resume from is indeed the most important for end-users;
your idea of using a 'resume' option is interesting, but I'm not yet sure it's
what we want.

Two points to consider:
* what do other tools do?  We would not want people that convert to or from
  initrd-tools or mkinitramfs to have to change their grub of fstab configuration
  to keep their swsusp working.  Only be incompatible if it can't be avoided.
  Ideally, avoid incompatibility even among distros.

* Could we avoid configuration altogether?  We could simply always do the resume
  code for all swap devices, if swsusp or swsusp2 is enabled in the kernel config.
  If the distro has swsusp in the kernel, this would mean users could start
  using swsusp without having to regenerate the initramfs; downside is they would
  have to edit the grub/lilo menu.

Attached some notes on swsusp I made earlier; untested so far.

I've started testing dmraid, and have only a limited supply of boxes to play
with (and limited time to play in ...) so it will be a while before I can test
the swsusp.

Regards,
Erik

-------------- next part --------------
Sat Oct 22 18:22:51 CEST 2005

Supporting Software Suspend

Linux comes with a feature that makes it possible to suspend operations:
write all RAM that is in use to swap device and then shutdown; then
on booting to read the RAM back from the swap device.  The nett result
is that after reboot the system is back in the state where it was just
before the shutdown, including all running processes and everything on
screen: you can resume work immediately.  The nice thing is that you can
use a deamon, acpid, to watch the system and issue the suspend command
automatically if the machine has been idle for a few minutes.

Swsusp is implemented in the context of power management: depending
on how long the system has been idle, you may want to bring devices to
a less active state, with reduced noise and reduced power consumption.
Blanking the screen is a possibility at one end of the spectrum, saving
the whole system to disk is at the other end.  Power management needs
kernel support, in part to be informed when the system has been idle for
a while, but also to negotiate with peripherals to what extent they can
cut down on their power consumption.

There are issues of course: some device drivers don't know how to hold
still while the system is being suspended, and network connections
can be interrupted if you save yourself to disk and just stop talking
for a while.  There is a 'hibernate' package which manages this by having a
configuration directory where packages can place scripts that need to
be invoked just before or after a suspend, and by have a list of modules
that need to be unloaded before suspending.

There used to be three different implementations of this idea, but currently
(2.6.14-rc4) two of these have been merged into mainline as 'swsusp'.
There are indications that 'swsusp2', an out-of-mainline implementation,
will also be merged back in.  www.suspend2.net
But note that a new and different approach is in the works: suspend3.
http://lwn.net/Articles/153203/

For yaird, the interesting part is how to recognise that a kernel can do
software suspend and what to do when a running system is being resumed.
Recognizing turns out to be fairly simple: if the relevant compile
time option has been given to the kernel, we must assume that it can do
software suspend.

How to handle the resume is trickier.  When booting the system,
a kernel command line option determines which partition will be used
for suspend/resume; for swsusp this can be any swap device,
for suspend2 it can be anything formatted like a swap device,
or even a plain file.  

To suspend a system with swsusp:
 - kernel with SOFTWARE_SUSPEND
 - first boot it with resume=22:2 or resume=/dev/hdc2
 - echo shutdown > /sys/power/disk
 - echo disk > /sys/power/state
 - [ at this point, the system goes to sleep. ]
 - at reboot, again pass the resume=22:2 kernel option
 - in the initramfs, before mounting root,
   echo 22:2 > /sys/power/resume
   (if you have echo burp here, it wont resume.)
   (echo /dev/hdc2 does not work either)
 - config_software_suspend=y in kernel

For swsusp2:
 - kernel with SUSPEND2
 - for debugging, boot with suspend_dbg=255 suspend_lvl=5 (6 is even more ...)
 - boot with resume2=swap:/dev/hdc2
   (there is also a filewriter, where you write to a plain file)
   (there is other magic if you swap not to a partition but to a file)
 - or boot with noresume2, which tells not to use resume2.
 - echo hello > /proc/software_suspend/do_suspend
 - reboot into initramfs, then before mounting root:
 - echo hello > /proc/software_suspend/do_resume

	The swap does not have to be active: you can have inactive,
	activated just before suspend, to ensure enough free room.

	While debugging, after boot,
	first see msg from swsusp:
		resume from /dev/hdc2,
		PM checking swsusp image
		swsusp: error -6 check for resume file
		pm resume from disk failed

		(this is probably because of hardcoded path in kernel,
		cmdline has resume2=, not resume= ...)

		Suspend2:
			core,
			compression driver loading,
			encrypt driver loading,
			swap writer loading

		Suspend2 later:
			swapwriter - signature found
			suspend enabled
			userui_prog not configured, disabled
			reading kernel & process data
			fail to init compressor filter
			image invalidated
			sanity check error

	Flawless reboot with "Compressor none" rather than "Compressor lzf"
	in /etc/hibernate/hibernate.conf.

	With modules/kernel/crypto/* all loaded in initramfs, also good restore,
	lzf 57% compression.

	But how do we decide what to load and in what order?

	At least for compression, suspend does crypto_alloc_tfm, which indirectly does modprobe.

	To get this working, adding /sbin/modprobe, modules.dep and kernel/crypto is sufficient.

So for swsusp:
	- if /sys/power/resume exists,
		echo $resume there.
		split out in major/minor.
	- but not if noresume is on cmdline.