Hi!
This removes pmdisk from kernel. Nobody maintains it and swsusp
provides same functionality (and more, pmdisk is actually fork of
swsusp code).
3 files need to be removed by hand, I did not want to obscure patch by
removing them like that (and you probably have slightly different
pmdisk.c, anyway).
rm arch/i386/power/pmdisk.S
rm kernel/power/disk.c
rm kernel/power/pmdisk.c
Pavel
PS: Alternatively, I'm wiling to kill swsusp, rename pmdisk to "swap
suspend", and submit patches to fix it. Its going to be slightly more
complicated, through...
--- linux/arch/i386/defconfig 2004-03-11 18:16:02.000000000 +0100
+++ linux-nopmdisk/arch/i386/defconfig 2004-03-15 20:15:35.000000000 +0100
@@ -117,7 +117,6 @@
#
CONFIG_PM=y
CONFIG_SOFTWARE_SUSPEND=y
-# CONFIG_PM_DISK is not set
#
# ACPI (Advanced Configuration and Power Interface) Support
--- linux/arch/i386/power/Makefile 2003-09-28 22:05:30.000000000 +0200
+++ linux-nopmdisk/arch/i386/power/Makefile 2004-03-15 20:15:54.000000000 +0100
@@ -1,3 +1,2 @@
obj-$(CONFIG_PM) += cpu.o
-obj-$(CONFIG_PM_DISK) += pmdisk.o
obj-$(CONFIG_SOFTWARE_SUSPEND) += swsusp.o
--- linux/kernel/power/Kconfig 2004-02-23 20:20:42.000000000 +0100
+++ linux-nopmdisk/kernel/power/Kconfig 2004-03-15 20:11:56.000000000 +0100
@@ -42,52 +42,3 @@
For more information take a look at Documentation/power/swsusp.txt.
-config PM_DISK
- bool "Suspend-to-Disk Support"
- depends on PM && SWAP
- ---help---
- Suspend-to-disk is a power management state in which the contents
- of memory are stored on disk and the entire system is shut down or
- put into a low-power state (e.g. ACPI S4). When the computer is
- turned back on, the stored image is loaded from disk and execution
- resumes from where it left off before suspending.
-
- This config option enables the core infrastructure necessary to
- perform the suspend and resume transition.
-
- Currently, this suspend-to-disk implementation is based on a forked
- version of the swsusp code base. As such, it's still experimental,
- and still relies on CONFIG_SWAP.
-
- More information can be found in Documentation/power/.
-
- If unsure, Say N.
-
-config PM_DISK_PARTITION
- string "Default resume partition"
- depends on PM_DISK
- default ""
- ---help---
- The default resume partition is the partition that the pmdisk suspend-
- to-disk implementation will look for a suspended disk image.
-
- The partition specified here will be different for almost every user.
- It should be a valid swap partition (at least for now) that is turned
- on before suspending.
-
- The partition specified can be overridden by specifying:
-
- pmdisk=/dev/<other device>
-
- which will set the resume partition to the device specified.
-
- One may also do:
-
- pmdisk=off
-
- to inform the kernel not to perform a resume transition.
-
- Note there is currently not a way to specify which device to save the
- suspended image to. It will simply pick the first available swap
- device.
-
--- linux/kernel/power/Makefile 2003-09-28 22:06:44.000000000 +0200
+++ linux-nopmdisk/kernel/power/Makefile 2004-03-15 20:12:13.000000000 +0100
@@ -1,5 +1,4 @@
obj-y := main.o process.o console.o pm.o
obj-$(CONFIG_SOFTWARE_SUSPEND) += swsusp.o
-obj-$(CONFIG_PM_DISK) += disk.o pmdisk.o
obj-$(CONFIG_MAGIC_SYSRQ) += poweroff.o
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
Pavel Machek <[email protected]> wrote:
>
> This removes pmdisk from kernel.
It would be unfortunate if Pat had more development planned or even
underway. Have we checked?
> PS: Alternatively, I'm wiling to kill swsusp, rename pmdisk to "swap
> suspend", and submit patches to fix it. Its going to be slightly more
> complicated, through...
People have suggested that I incorporate swsusp2. Where does this fit into
things?
Hi!
> Pavel Machek <[email protected]> wrote:
> >
> > This removes pmdisk from kernel.
>
> It would be unfortunate if Pat had more development planned or even
> underway. Have we checked?
Last time I attempted pmdisk removal, he did not react. Lets try one
more time.
> > PS: Alternatively, I'm wiling to kill swsusp, rename pmdisk to "swap
> > suspend", and submit patches to fix it. Its going to be slightly more
> > complicated, through...
>
> People have suggested that I incorporate swsusp2. Where does this fit into
> things?
I believe that you don't want swsusp2 in 2.6. It has hooks all over
the place:
Pavel
Documentation/kernel-parameters.txt | 9
Documentation/power/swsusp2.txt | 495 +++++++++++++++++++++++++++++++
arch/arm/kernel/ecard.c | 6
arch/i386/kernel/apm.c | 8
arch/i386/kernel/process.c | 25 +
arch/i386/kernel/signal.c | 5
arch/i386/kernel/smp.c | 2
arch/i386/mm/pageattr.c | 2
arch/i386/power/Makefile | 1
arch/i386/power/cpu.c | 8
arch/i386/power/swsusp2-asm.S | 259 ++++++++++++++++
arch/i386/power/swsusp2.c | 130 ++++++++
arch/ppc/Kconfig | 2
arch/ppc/Makefile | 1
arch/ppc/kernel/signal.c | 6
arch/ppc/kernel/vmlinux.lds.S | 6
arch/ppc/power/Makefile | 2
arch/ppc/power/cpu.c | 72 ++++
arch/ppc/power/cpu_reg.S | 325 ++++++++++++++++++++
arch/ppc/power/swsusp2-asm.S | 51 +++
arch/ppc/power/swsusp2-copyback.S | 73 ++++
arch/ppc/power/swsusp2.c | 170 ++++++++++
drivers/acpi/sleep/proc.c | 7
drivers/block/loop.c | 3
drivers/char/hvc_console.c | 6
drivers/char/keyboard.c | 84 +++++
drivers/char/n_tty.c | 4
drivers/char/tty_io.c | 14
drivers/char/vt.c | 20 -
drivers/ide/ide-disk.c | 3
drivers/ieee1394/nodemgr.c | 12
drivers/input/serio/serio.c | 11
drivers/md/md.c | 3
drivers/media/video/msp3400.c | 14
drivers/media/video/tvaudio.c | 8
drivers/message/i2o/i2o_block.c | 11
drivers/message/i2o/i2o_core.c | 23 +
drivers/mtd/mtdblock.c | 4
drivers/net/8139too.c | 2
drivers/net/irda/sir_kthread.c | 10
drivers/net/wireless/airo.c | 2
drivers/parport/ieee1284.c | 4
drivers/pcmcia/cs.c | 11
drivers/scsi/scsi_error.c | 16 -
drivers/serial/8250.c | 100 ++++++
drivers/usb/core/hub.c | 10
drivers/usb/storage/usb.c | 14
fs/buffer.c | 89 ++++-
fs/dcache.c | 5
fs/devfs/base.c | 14
fs/exec.c | 18 +
fs/fcntl.c | 19 +
fs/jbd/journal.c | 20 -
fs/jffs/intrep.c | 15
fs/jffs2/background.c | 18 -
fs/jfs/jfs_logmgr.c | 24 -
fs/jfs/jfs_txnmgr.c | 61 ++-
fs/lockd/clntlock.c | 8
fs/lockd/clntproc.c | 6
fs/lockd/svc.c | 12
fs/locks.c | 8
fs/namei.c | 54 +++
fs/namespace.c | 16 -
fs/nfsd/nfssvc.c | 8
fs/open.c | 84 +++++
fs/pipe.c | 4
fs/proc/generic.c | 8
fs/proc/kmsg.c | 9
fs/read_write.c | 66 +++-
fs/stat.c | 41 ++
fs/super.c | 5
fs/sysfs/file.c | 4
fs/xfs/linux/xfs_buf.c | 11
fs/xfs/linux/xfs_super.c | 11
include/asm-i386/cpufeature.h | 1
include/asm-i386/mtrr.h | 4
include/asm-i386/tlbflush.h | 5
include/asm-ppc/suspend.h | 14
include/linux/pagemap.h | 5
include/linux/sched.h | 8
include/linux/selection.h | 4
include/linux/suspend-version-specific.h | 74 ++++
include/linux/suspend.h | 75 ----
include/linux/suspend1.h | 76 ++++
kernel/exit.c | 7
kernel/fork.c | 7
kernel/module.c | 27 +
kernel/panic.c | 5
kernel/power/Kconfig | 102 ++++++
kernel/power/Makefile | 12
kernel/power/console.c | 51 ---
kernel/power/disk.c | 3
kernel/power/main.c | 3
kernel/power/pmdisk.c | 2
kernel/power/process.c | 128 --------
kernel/power/swsusp.c | 2
kernel/sched.c | 10
kernel/softirq.c | 3
kernel/sys.c | 6
kernel/workqueue.c | 3
mm/page_alloc.c | 30 +
mm/pdflush.c | 8
mm/swapfile.c | 5
mm/vmscan.c | 443 ++++++++++++++++-----------
net/bluetooth/bnep/core.c | 11
net/bluetooth/rfcomm/core.c | 11
net/socket.c | 21 +
net/sunrpc/sched.c | 12
net/sunrpc/svcsock.c | 8
109 files changed, 3254 insertions(+), 624 deletions(-)
This is one small example what swsusp2 needs:
diff -ruN linux-2.6.2/fs/buffer.c software-suspend-linux-2.6.2/fs/buffer.c
--- linux-2.6.2/fs/buffer.c 2004-02-06 17:27:46.000000000 +1300
+++ software-suspend-linux-2.6.2/fs/buffer.c 2004-02-06 17:41:09.000000000 +1300
@@ -37,6 +37,7 @@
#include <linux/bio.h>
#include <linux/notifier.h>
#include <linux/cpu.h>
+#include <linux/init.h>
#include <asm/bitops.h>
static void invalidate_bh_lrus(void);
@@ -229,16 +230,24 @@
*/
int fsync_super(struct super_block *sb)
{
- sync_inodes_sb(sb, 0);
- DQUOT_SYNC(sb);
- lock_super(sb);
- if (sb->s_dirt && sb->s_op->write_super)
- sb->s_op->write_super(sb);
- unlock_super(sb);
- if (sb->s_op->sync_fs)
- sb->s_op->sync_fs(sb, 1);
- sync_blockdev(sb->s_bdev);
- sync_inodes_sb(sb, 1);
+#ifdef CONFIG_SOFTWARE_SUSPEND2
+ /* A safety net. During suspend, we might overwrite
+ * memory containing filesystem info. We don't then
+ * want to sync it to disk. */
+ if (likely(!(swsusp_state & FREEZE_UNREFRIGERATED)))
+#endif
+ {
+ sync_inodes_sb(sb, 0);
+ DQUOT_SYNC(sb);
+ lock_super(sb);
+ if (sb->s_dirt && sb->s_op->write_super)
+ sb->s_op->write_super(sb);
+ unlock_super(sb);
+ if (sb->s_op->sync_fs)
+ sb->s_op->sync_fs(sb, 1);
+ sync_blockdev(sb->s_bdev);
+ sync_inodes_sb(sb, 1);
+ }
return sync_blockdev(sb->s_bdev);
}
@@ -251,12 +260,20 @@
int fsync_bdev(struct block_device *bdev)
{
struct super_block *sb = get_super(bdev);
+ int result = 0;
+ DECLARE_SWSUSP_LOCAL_VAR;
+
+ SWSUSP_ACTIVITY_START(PF_SYNCTHREAD);
+ current->flags |= PF_SYNCTHREAD;
if (sb) {
int res = fsync_super(sb);
drop_super(sb);
return res;
}
- return sync_blockdev(bdev);
+ result = sync_blockdev(bdev);
+ current->flags &= ~PF_SYNCTHREAD;
+ SWSUSP_ACTIVITY_END;
+ return result;
}
/*
@@ -265,20 +282,34 @@
*/
static void do_sync(unsigned long wait)
{
- wakeup_bdflush(0);
- sync_inodes(0); /* All mappings, inodes and their blockdevs */
- DQUOT_SYNC(NULL);
- sync_supers(); /* Write the superblocks */
- sync_filesystems(0); /* Start syncing the filesystems */
- sync_filesystems(wait); /* Waitingly sync the filesystems */
- sync_inodes(wait); /* Mappings, inodes and blockdevs, again. */
- if (!wait)
- printk("Emergency Sync complete\n");
+#ifdef CONFIG_SOFTWARE_SUSPEND2
+ /* A safety net. During suspend, we might overwrite
+ * memory containing filesystem info. We don't then
+ * want to sync it to disk. */
+ if (likely(!(swsusp_state & FREEZE_UNREFRIGERATED)))
+#endif
+ {
+ wakeup_bdflush(0);
+ sync_inodes(0); /* All mappings, inodes and their blockdevs */
+ DQUOT_SYNC(NULL);
+ sync_supers(); /* Write the superblocks */
+ sync_filesystems(0); /* Start syncing the filesystems */
+ sync_filesystems(wait); /* Waitingly sync the filesystems */
+ sync_inodes(wait); /* Mappings, inodes and blockdevs, again. */
+ if (!wait)
+ printk("Emergency Sync complete\n");
+ }
}
asmlinkage long sys_sync(void)
{
+ DECLARE_SWSUSP_LOCAL_VAR;
+
+ SWSUSP_ACTIVITY_START(PF_SYNCTHREAD);
+ current->flags |= PF_SYNCTHREAD;
do_sync(1);
+ current->flags &= ~PF_SYNCTHREAD;
+ SWSUSP_ACTIVITY_END;
return 0;
}
@@ -319,6 +350,10 @@
struct file * file;
struct address_space *mapping;
int ret, err;
+ DECLARE_SWSUSP_LOCAL_VAR;
+
+ SWSUSP_ACTIVITY_START(PF_SYNCTHREAD);
+ current->flags |= PF_SYNCTHREAD;
ret = -EBADF;
file = fget(fd);
@@ -349,6 +384,8 @@
out_putf:
fput(file);
out:
+ current->flags &= ~PF_SYNCTHREAD;
+ SWSUSP_ACTIVITY_END;
return ret;
}
@@ -357,6 +394,10 @@
struct file * file;
struct address_space *mapping;
int ret, err;
+ DECLARE_SWSUSP_LOCAL_VAR;
+
+ SWSUSP_ACTIVITY_START(PF_SYNCTHREAD);
+ current->flags |= PF_SYNCTHREAD;
ret = -EBADF;
file = fget(fd);
@@ -384,6 +425,8 @@
out_putf:
fput(file);
out:
+ current->flags &= ~PF_SYNCTHREAD;
+ SWSUSP_ACTIVITY_END;
return ret;
}
@@ -1071,6 +1114,10 @@
* async buffer heads in use.
*/
free_more_memory();
+#ifdef CONFIG_SOFTWARE_SUSPEND2
+ if (suspend_task == current->pid)
+ cleanup_finished_swsusp_io();
+#endif
goto try_again;
}
@@ -2800,7 +2847,7 @@
*
* try_to_free_buffers() is non-blocking.
*/
-static inline int buffer_busy(struct buffer_head *bh)
+inline int buffer_busy(struct buffer_head *bh)
{
return atomic_read(&bh->b_count) |
(bh->b_state & ((1 << BH_Dirty) | (1 << BH_Lock)));
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
Pavel Machek <[email protected]> wrote:
>
> > It would be unfortunate if Pat had more development planned or even
> > underway. Have we checked?
>
> Last time I attempted pmdisk removal, he did not react. Lets try one
> more time.
OK. Best use his current email address..
> I believe that you don't want swsusp2 in 2.6. It has hooks all over
> the place:
> ...
> 109 files changed, 3254 insertions(+), 624 deletions(-)
Ahem. Agreed.
Most of those changes are hooks to make the freezer for more reliable.
That part of the functionality could be isolated from the bulk of
suspend2. Would that make you happy?
Nigel
On Tue, 2004-03-16 at 10:21, Andrew Morton wrote:
> Pavel Machek <[email protected]> wrote:
> >
> > > It would be unfortunate if Pat had more development planned or even
> > > underway. Have we checked?
> >
> > Last time I attempted pmdisk removal, he did not react. Lets try one
> > more time.
>
> OK. Best use his current email address..
>
> > I believe that you don't want swsusp2 in 2.6. It has hooks all over
> > the place:
> > ...
> > 109 files changed, 3254 insertions(+), 624 deletions(-)
>
> Ahem. Agreed.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)
Evolution (n): A hypothetical process whereby infinitely improbable events occur
with alarming frequency, order arises from chaos, and no one is given credit.
Nigel Cunningham <[email protected]> wrote:
>
> On Tue, 2004-03-16 at 10:21, Andrew Morton wrote:
> > Pavel Machek <[email protected]> wrote:
> > >
> > > I believe that you don't want swsusp2 in 2.6. It has hooks all over
> > > the place:
> > > ...
> > > 109 files changed, 3254 insertions(+), 624 deletions(-)
> >
> > Ahem. Agreed.
>
> Most of those changes are hooks to make the freezer for more reliable.
> That part of the functionality could be isolated from the bulk of
> suspend2. Would that make you happy?
It would make us happier. Even happier would be a series of small, well
explained patches which bring swsusp into a final shape upon which more
than one developer actually agrees.
These wholesale replacements and deletions are an indication that something
has gone wrong with the development process here.
Hi.
On Tue, 2004-03-16 at 10:53, Andrew Morton wrote:
> Nigel Cunningham <[email protected]> wrote:
> >
> > On Tue, 2004-03-16 at 10:21, Andrew Morton wrote:
> > > Pavel Machek <[email protected]> wrote:
> > > >
> > > > I believe that you don't want swsusp2 in 2.6. It has hooks all over
> > > > the place:
> > > > ...
> > > > 109 files changed, 3254 insertions(+), 624 deletions(-)
> > >
> > > Ahem. Agreed.
> >
> > Most of those changes are hooks to make the freezer for more reliable.
> > That part of the functionality could be isolated from the bulk of
> > suspend2. Would that make you happy?
>
> It would make us happier. Even happier would be a series of small, well
> explained patches which bring swsusp into a final shape upon which more
> than one developer actually agrees.
I'd love to do that too. Unfortunately I'm really busy with my new job,
so things have progressed far more slowly than I'd have liked. I'm also
not sure how to deal with some of the changes that just about completely
rewrite sections.
> These wholesale replacements and deletions are an indication that something
> has gone wrong with the development process here.
I spent a long time trying to get the freezer working reliably with the
kind of implementation Pavel uses. The problem I kept running into time
and again was that you can't know dependancies between processes when it
comes to signalling them; process A might happily be frozen, but then
process B can't be frozen becaue it is waiting on something process A
has (eg ls/nfsd). By tracking which processes are in those
'can't-be-frozen-here' sections, I have managed to make the freezer far
more reliable, even under high load. Michael Frank has done some extreme
stress testing and can verify this.
Nigel
--
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)
Evolution (n): A hypothetical process whereby infinitely improbable events occur
with alarming frequency, order arises from chaos, and no one is given credit.
Hi!
> Most of those changes are hooks to make the freezer for more reliable.
> That part of the functionality could be isolated from the bulk of
> suspend2. Would that make you happy?
Yes, that would be very good. It would make it easy to see actual
changes..
[I still do not understand why those hooks are neccessary... kill
-SIGSTOP works, right?]
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
Hi.
On Tue, 2004-03-16 at 13:56, Pavel Machek wrote:
> Hi!
>
> > Most of those changes are hooks to make the freezer for more reliable.
> > That part of the functionality could be isolated from the bulk of
> > suspend2. Would that make you happy?
>
> Yes, that would be very good. It would make it easy to see actual
> changes..
>
> [I still do not understand why those hooks are neccessary... kill
> -SIGSTOP works, right?]
Not always. Take for example the case where you have an NFS mount and
happen to be doing an ls when the suspend cycle is started. If you
signal the NFSd threads before the ls thread, the NFS threads will
refrigerate okay, but the ls thread will fail to stop because it's
waiting for data from the nfsd threads.
The best way to test the reliability of the current freezer
implementation is to grab Michael's test patches. They can load the
system down with NFS access, kernel compiles, benchmarks and so on.
You'll quickly see the freezer fail. My implementation handles those
loads flawlessly, and where problems are found, they're easily fixed.
Regards,
Nigel
--
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)
Evolution (n): A hypothetical process whereby infinitely improbable events occur
with alarming frequency, order arises from chaos, and no one is given credit.
On ?t 16-03-04 10:16:48, Romano Giannetti wrote:
> On Mon, Mar 15, 2004 at 09:57:52PM +0100, Pavel Machek wrote:
> > Hi!
> > > Pavel Machek <[email protected]> wrote:
> > > >
> > > > This removes pmdisk from kernel.
> > >
>
> Are you sure swsusp is equivalent? Last time I tried (2.6.1, I am in serious
> time shortage in this period) swsusp did not work on my Vaio fx-701, while
> PMDISK yes (ACPI enabled). I will try to test again in this weekend.
Yes, I'm pretty sure. There may be some bug in both of them, but they
do the same thing. (And swsusp should have slightly lower ammount of
bugs).
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On ?t 16-03-04 12:27:36, Nigel Cunningham wrote:
> On Tue, 2004-03-16 at 13:56, Pavel Machek wrote:
> >
> > > Most of those changes are hooks to make the freezer for more reliable.
> > > That part of the functionality could be isolated from the bulk of
> > > suspend2. Would that make you happy?
> >
> > Yes, that would be very good. It would make it easy to see actual
> > changes..
> >
> > [I still do not understand why those hooks are neccessary... kill
> > -SIGSTOP works, right?]
>
> Not always. Take for example the case where you have an NFS mount and
> happen to be doing an ls when the suspend cycle is started. If you
> signal the NFSd threads before the ls thread, the NFS threads will
> refrigerate okay, but the ls thread will fail to stop because it's
> waiting for data from the nfsd threads.
Hmm, you are right that with dead nfs server, kill -SIGSTOP will fail
on ls, and similary current refrigerator will fail. I think we can
live with that.
I agree that two-stage suspend is probably neccessary (userland first,
kernel than); but that should be possible without that big changes,
right?
> The best way to test the reliability of the current freezer
> implementation is to grab Michael's test patches. They can load the
> system down with NFS access, kernel compiles, benchmarks and so on.
> You'll quickly see the freezer fail. My implementation handles those
> loads flawlessly, and where problems are found, they're easily fixed.
Your solution is more reliable, thats right.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
15 March 2004 12:57, Pavel Machek wrote:
> > > PS: Alternatively, I'm wiling to kill swsusp, rename pmdisk to
> > > "swap suspend", and submit patches to fix it. Its going to be
> > > slightly more complicated, through...
> >
> > People have suggested that I incorporate swsusp2. Where does
> > this fit into things?
>
> I believe that you don't want swsusp2 in 2.6. It has hooks all over
> the place:
>
but maybe that's just why it happens to work for way many more people?
Or does anyone care about that?
Fedor
PS. Sorry, just my 2 cents
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAVlk3w4m50RG4juoRAt8bAJ95Xl08+o5qhbWINtjnYbMdLlpRbwCeL9n+
7d5IsT79sCTSi36oF7od6Bs=
=aIb4
-----END PGP SIGNATURE-----
Hi.
On Tue, 2004-03-16 at 23:17, Pavel Machek wrote:
> Hmm, you are right that with dead nfs server, kill -SIGSTOP will fail
> on ls, and similary current refrigerator will fail. I think we can
> live with that.
>
> I agree that two-stage suspend is probably neccessary (userland first,
> kernel than); but that should be possible without that big changes,
> right?
It would certainly be simple to change to a two stage freeze. I don't
think I've tried that, so I'll cut the code and give it a try.
Regards,
Nigel
--
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)
Evolution (n): A hypothetical process whereby infinitely improbable events occur
with alarming frequency, order arises from chaos, and no one is given credit.
On Tue, Mar 16, 2004 at 10:16:48AM +0100, I wrote:
> Are you sure swsusp is equivalent? Last time I tried (2.6.1, I am in serious
> time shortage in this period) swsusp did not work on my Vaio fx-701, while
> PMDISK yes (ACPI enabled). I will try to test again in this weekend.
Well, I can confirm that, as Mr. Machek said, swsusp and pmdisk gave me the
same functionality on a Vaio fx-701 laptop. I do not know why 2.6.1 didn't
work, but there have been a lot of ACPI updates, maybe that's the key.
Before suspending I unload pcmcia, sound (alsa), autofs, and usb hid
modules. If someone is interested I canb try not to unload something an
report back what happens.
I will try during the long weekend (tomorrow's holiday here) the bleeding
edge patches from Nigel, and report back.
Thanks to all,
Romano
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569