Bug#329319: [Yaird-devel] Bug#329319: yaird: swsusp not all that hard
On Tue, 13 Dec 2005, Sven Luther wrote: My impression is that they use the resume= option on the kernel command line, which is then parsed by initrd-tools or whatever. I feel the sane thing to do is to support all three possible ways : 1) have the resume= kernel command line option provided by the user / grub/lilo/yaboot/etc override the detected partition. This is always a good idea, as we showed with the root= kernel command line option, and will allow the user to recover more easily from mistakes and such. 2) have yaird look at the resume option in /etc/fstab as suggested here. Not sure if this is the best thing to do though. 3) have it specified/specifiable in /etc/yaird.conf. This is exactly what my patch implements. The real question being what other tools who do the suspend step usually use for configuration, the resume step is rather easy once we know that. There is the 'hibernate' package, but I haven't looked at it. It seems a little heavyweight for my purposes, as I don't need to "load and unload modules, various hacks needed to get some video cards to resume properly under X, restart networking and system services" which it advertises as its purpose. Just writing to /sys/power/state seems sufficient; the other things seem like they are more properly bugs in the kernel which ought to be fixed, not hacked around. There are also the following packages: toshutils, fnfxd, athcool, etc. I think the proper place for support is in the acpid package, with possibly a separate machine-specific package to flesh out the support. But it seems that ACPI supports a 'sleep' button, so we should be able to implement basic support without machine-specific stuff. Notice that one thought i had about swsusp is to have multiple swap partitions associated with multiple non-overlapping partition sets and be able to resume in the one or the other, so i believe your idea will kill this kind of setup. No, you can always specify a particular resume partition for this case, either on the kernel command-line, or in etc/fstab. --scott Diplomat bomb Bejing SLINC KUHOOK explosives genetic LCPANGS Sugar Grove overthrow security AVBUSY KUBARK PAPERCLIP hack Nazi Honduras cracking ( http://cscott.net/ ) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329319: [Yaird-devel] Bug#329319: yaird: swsusp not all that hard
On Mon, Dec 12, 2005 at 11:59:05PM +0100, Erik van Konijnenburg wrote: > 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. My impression is that they use the resume= option on the kernel command line, which is then parsed by initrd-tools or whatever. I feel the sane thing to do is to support all three possible ways : 1) have the resume= kernel command line option provided by the user / grub/lilo/yaboot/etc override the detected partition. This is always a good idea, as we showed with the root= kernel command line option, and will allow the user to recover more easily from mistakes and such. 2) have yaird look at the resume option in /etc/fstab as suggested here. Not sure if this is the best thing to do though. 3) have it specified/specifiable in /etc/yaird.conf. The real question being what other tools who do the suspend step usually use for configuration, the resume step is rather easy once we know that. > * 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. Notice that one thought i had about swsusp is to have multiple swap partitions associated with multiple non-overlapping partition sets and be able to resume in the one or the other, so i believe your idea will kill this kind of setup. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329319: yaird: swsusp not all that hard
On Mon, 12 Dec 2005, Erik van Konijnenburg wrote: 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. I don't know what other tools do -- swsusp seems to be an "experimenters only" option right now, as far as I can tell. My goal was to make Debian Do The Right Thing By Default and make it easier for people to try this stuff out. * 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. Well, swsusp needs to be told what partition to suspend *to*. The current swsusp code sets the 'to' directory as a side-effect of attempting the suspend 'from'. Trying to resume from *all* the swap partitions wouldn't be terrible, but it still requires parsing the /etc/fstab to find out which partitions those are. But maybe the default should be "resume from all, *unless* one is marked with a 'resume' tag". That way (those few) people with multiple swap partitions can still specify which they want. And resuming from all will cause us to suspend to the last partition tested, by default. It would be nice to use the 'largest' by default -- but this can always be overriden in the actual suspend code (not the resume code) which is perhaps where such policy decisions belong. I can turn the crank on another patch if something like this sounds like what you'd want. Attached some notes on swsusp I made earlier; untested so far. Your characterisation of software suspend seems a little off. "[D]epending 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." I think the primary use of software suspend, rather, is by *laptop users*, who could care less about "reduced noise" but rather need to save their working state without draining their batteries. Detecting "how long the system has been idle" is not really a big concern; most suspends are triggered by explicit user action (ie, by closing the lid or by using a special key sequence). In your notes on suspending with swsusp, you don't need the kernel option, as long as you do the echo to /sys/power/resume (before the suspend, too). 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. My philosophy here is to get *something* (non-harmful!) in yaird ASAP, which will then (hopefully) provoke comments and perhaps revisions. I don't think the features are well-known enough to do a "perfect" design ex nihilo. For example, if you roll out very basic support for swsusp2 (which my patch provides) with somewhat more complete support for swsusp, I expect that some swsusp2 user will be motivated to complete the swsusp2 support. But at the moment, since the stock debian kernel supports swsusp (but not swsusp2), it seems that yaird should (at least) support swsusp. --scott arrangements Morwenstow TASS SGUAT LICOZY Marxist ammunition ODYOKE COBRA JANE SHERWOOD DC counter-intelligence BATF radar Kojarena assassinate ( http://cscott.net/ ) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329319: yaird: swsusp not all that hard
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 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 n
Bug#329319: yaird: swsusp not all that hard
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 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-rc5 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages yaird depends on: ii cpio 2.6-9 GNU cpio -- a program to manage ar ii dash 0.5.3-1 The Debian Almquist Shell ii libc62.3.5-8.1 GNU C Library: Shared libraries an ii libhtml-template-perl2.7-1 HTML::Template : A module for usin ii libparse-recdescent-perl 1.94.free-1 Generates recursive-descent parser ii perl 5.8.7-8 Larry Wall's Practical Extraction yaird recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
