Software suspend test notes

2.2.19-swsusp

• Tested on my old laptop.
• When resuming in X11 mode the xterm windows are frozen. They remain blank until a timeout occured. This may have to do with loopback network interface. Emacs window is not frozen and it is possible to open new windows that will work perfectly.
• After resuming, processus init seems to run at 100% CPU. I think this is a known issue but I don't remember how it can be solved.
• From time to time I cannot resume in X11 mode. The display have disppeared and if I switch to the F7 screen I get stuck (no other choice but to shut off power)

2.2.20-swsusp

2.4.13-swsusp

• This patch was not heavily tested, but I had partial success on my new laptop for suspending in text mode. Unfortunately, I have other kind of problems with this laptop, so that I don't know for sure if it works.

2.4.14-swsusp

• I've tried this patch on my new laptop but it seems less stable than the 2.4.13 kernel (also patched). I don't think this is due to the patch.
• I've also tried it on my old laptop but I got an error -12 on resuming and went into e2fsck.

2.4.16-swsusp

• I'm currently experimenting on this patch using ext3 journaling filesystem on my new laptop. The patch seems stable enough to be tested by others. Prepare to experience hangs but I didn't loose any data for the moment. Suspend/resume seems OK in console mode. In X11 mode, one has to switch to console before suspending (at least that's my observation). For my laptop, X11 screen is correctly resumed but the least modification (mouse move, press return in a window...) leads to a screen garbage and the only thing to do then is a Ctrl-Alt-Suppr (SysRq is not functionning on this laptop) which seems to halt the computer, but I guess that the root partition cannot be unmounted because it is checked on reboot (and sometimes I obtain unexpected inconsistencies). The X11 hanging seems due to uncorrect treatment of suspension by agpgart driver (under investigation).
  Don't trust me anymore! I experienced really bad damage on my root filesystem. This however seems to be linked with an fsck bug that may be fixed by this patch (thanks Pavel). Please, do not use ext3 filesystem and suspension unless you really know what you do.

2.4.17-swsusp (v9alpha)

• Not really tested yet. I just compiled it and made a suspend/resume cycle in console mode.
• I'm currently trying to adapt 2.5.2-pre7 patch from Pavel to 2.4.1[78] kernel. I will put the result as soon as 2.4.18 kernel is published.
• Still having a 100% CPU problem with kernel threads such as kswapd or kjournald. Otherwise suspend/resuming seems to work under ext3 (at least in console mode).

2.4.17-swsusp (v21alpha)

• Should suspend/resume cycle in console mode on IDE disks.
• I made a trial to fix the 100% CPU problem with kernel threads. It seems to work for kswapd but not kjournald. Otherwise suspend/resuming seems to work under ext3 (at least in console mode).
• After a lot of suspend/resume cycle, it seems that the machine slows down.

2.4.17-swsusp (v23alpha)

• Seems to work less reliably than v21alpha under ext3. Some errors appear in filesystem after a lot of suspend/resume cycles. Those errors were correctly detected and corrected by e2fsck on reboot.
• No slow down detected but kjournald still sucks 100% CPU.
• After modification of patch, seems to work without 100% CPU problem.
• Again a smashed root inode using ext3. It definitely seems that PF_IOTHREAD is NOT the right way to suspend kjournald.

2.4.18-swsusp (v24alpha)

• Tested intensively on virtual machine.
• Should work reliably with ext3.
• No more problem with kernel threads sucking CPU.
• From time to time, suspension hangs on a bdflush oops. This doesn't seem to corrupt data, even under ext3.
• After 30 suspend/resume cycles I observe that some programs like vi or login segfault.
• Patch generates rejects due to keywords substitution by CVS. Sorry for that, I forgot the -ko option. The rejects are likely to be non important and ignored.

2.4.18-swsusp (v25alpha)

• Tested on virtual machine.
• bdflush oops seems to have disappeared.
• segfault problem is still there (at least on the virtual machine after a great number of cycles)
• It appears on my real machine that resume of non root ext3 partition is buggy :-( Virtual machine had only a single ext3 root partition. More precisely each partition has its own kjournald thread and I think that some deadlocks can occur with logging.
• Patch generates rejects due to keywords substitution by CVS.

2.4.18-swsusp (v26alpha)

• Tested on virtual machine.
• Come back to a simpler freezing of kjournald otherwise deadlocking of journal threads is possible.
• segfault problem seems to have disappeared, but I suspect this only occur when a suspension cannot stop all tasks and resume itself.
• I now use it on my real machine and I will see.
• From time to time, I observe little (however frightening) data corruption on ext3 partition. I suspect that once again suspending is revealing some bugs in filesystem code, this time ext3.
• Ext3 problems can really damage the filesystem. This may be caused by aborted suspension. I suggest use the following command at least for root partition:

  tune2fs -e panic /dev/hdaX
  

  This will cause a panic as soon as errors like the ones I observe occured:

  Mar  2 21:18:46 fuji kernel: EXT3-fs error (device ide0(3,9)):
  ext3_new_block: Allocating block in system zone - block = 11
  Mar  2 21:18:47 fuji kernel: EXT3-fs error (device ide0(3,9)):
  ext3_free_blocks: Freeing blocks in system zones - Block = 11, count = 1
  

  Those are the signal for pretty bad data corruption.
• I experienced one more time a bad data corruption. I'm however not sure whether that's caused by ext3 or other part of suspension, or even if it's not remaining from a previous test since recovering partition is not an exact science. For the moment, I use an ext2 partition as root and ext3 for all others.

2.4.18-swsusp (v27alpha)

• No time for testing.

2.4.18-swsusp (v29alpha)

• I've done 30 suspend/resume cycles on virtual machine using ext3 and four swap devices (one partition for suspension, one partition with higher priority, one partition with lower priority, one swapfile with higher partition) and it seems to work.
• No more kernel oops for the moment.
• I now use it on my real machine and I will see.
• As the system seems stable, I have made my root partition ext3: this was formerly the signal for bad corruption after a few suspends.

2.4.18-swsusp (v30alpha = v0beta)

• I use the following optional patches: nodebug, apm, agpgart, memeat, makefile.
• The patch seems to work for me without the following optional patch: memeat (when not too many applications are launched), twopasses.
• I really need the following optional patches: memeat, agpgart.