I'm trying to get s2disk to work with a 2.6.19 kernel.

When I use the s2disk command, the system saves itself to my swap partition and shuts down, as expected. But it doesn't resume: it just does a normal boot (although complains that it can't activate swap).

However, using the kernel package from unstable, linux-image-2.6.18-3-686 version 2.6.18-8, s2disk and resume work fine.

I created my 2.6.19 kernel package using make-kpkg --initrd kernel_image modules_image, and installed it with apt-get. I use LILO, and the stanzas for the stock 2.6.18 kernel and my 2.6.19 kernel (and their initrds) are identical. I've unpacked the initrd.img-* for each kernel, and `diff -r`ed the contents, and they are identical, except for the contents of lib/modules/kernel/2.6*/kernel, and etc/udev/rules.d/z25_persistent*

The boot loader entries, and the initramfs, are the same. Therefore, the problem is to do with a difference between the kernels. Right? Can anyone tell me what this difference is? Or point out the flaw in my argument?

Did you try with the vanilla 2.6.18 ?
Probably that debian added a patch for suspend to work (some drivers don't have suspend and resume functions yet, like disk and network)

An easy thing I would do:
Patch your kernel with the latest patch:
http://kernel.org/pub/linux/kernel/v....19-rc6.tar.gz
And try again

Thanks for your suggestions. I've tried another two kernels. First, as suggested, I patched my 2.6.19 with http://kernel.org/pub/linux/kernel/v....6.20-rc1.bz2; second I used the debian source package linux-source-2.6.18 version 2.6.18-8. Neither would resume.

A quick summary: *all* the kernels I've tried will suspend (ie s2disk runs and shuts down the system), but *only* the debian kernel (package linux-image-2.6.18-3-686, v2.6.18-8) also resumes. That is, it's the only kernel that even *recognises* that there is a suspended system on disk that can be resumed from. It also tries to resume from an image created by s2disk run on any of the other kernels (although gives a warning that it was created by a different kernel.)

So, it seems that it's a problem with the way I configure, compile, package or install my kernels, not a problem with the kernels themselves. I do something different to the debian package maintainer - any idea what?

Interesting, this problematic kernels don't recognized there is a suspended image. You mean you see the resume message and it says no resume image found or it simplies doesn't call /bin/resume? This point is important.
Be sure that your initrd contains everything.
You can check for kernel config by comparing /boot/configxx files.
For initrd:
mkdir /tmp/initrd
cd /tmp/initrd
zcat /boot/initrd.img-`uname -r` | cpio -idv
Then have a look at etc/uswsusp.conf (thats the new configuration file for the new uswsusp package), and in scripts/local-premount/ uswsusp and resume files. Without this, you're dead.

You can always look at the patch that debian applied on this kernel. Either by apt-get source linux-image-2.6.18xxx and look at the diff file. Or there is an official webpage summarizing these patchs but I can't find it once again arggg.

I might try the 2.6.19 these days, I'm getting impatient :-) If I have some result, I will tell you.

As a blind check, you can also call suspend like this:
echo platform > /sys/power/disk; echo disk > /sys/power/state
See if it works.

All fixed! Thanks for your help.

It turns out to be a kernel configuration issue. You have to set the CONFIG_BLK_DEV_RAM and CONFIG_BLK_DEV_INITRD options in .config. Thanks to IBM for that: a very good article on the boot process and on initrd in particular. If you don't set those options, the kernel won't even try to load an initrd image, and the uswsusp system depends on the initrd system, so it won't work.

So s2disk/resume work perfectly for me now.