5. Using TuxOnIce

5.1 TuxOnIce doesn't seem to do anything (or: I upgraded to the latest TuxOnIce and my machine no longer suspends! Instead, it shuts down all drivers, etc and then starts resuming.)

Suspend2/TuxOnIce's kernel interface has been through numerous modifications. We recommend using the hibernate script (also available from tuxonice.net). If you ensure you have the latest version of that, things should start working again (assuming Nigel just made another modification in this area).

And if you are still having little or no success...

• Check you have a resume=swap:/dev/hdXX option on your kernel commandline in your bootloader (eg, LILO or GRUB).
• Grep through dmesg for 'Suspend2' or 'TuxOnIce' to see if it is giving any error messages on boot.
• Check that in your .config you have the following lines:

  CONFIG_PM=y
  CONFIG_SUSPEND2=y (or CONFIG_TOI* after 2.2.10.2)
  CONFIG_SUSPEND2_SWAP=y (TOI_SWAP)
  ...
  CONFIG_CRYPTO_LZF=y
  

• Did you really patch your kernel source?

  bzcat /path/to/tuxonice-2.x.y-for-2.6.z.patch.bz2 | patch -p1 -b

  should not return any failures.

• Did you run make dep after patching? (2.4 only)
• Are you really booting your freshly-compiled kernel? Run uname -a and check the timestamp - it should match the time of compilation.
• To be absolutely certain there's nothing stale hanging about:

  SAVE your .config somewhere outside the kernel tree, run make mrproper, copy the .config back and then run make oldconfig dep bzImage modules.

5.2 It doesn't power off, but hangs forever.

If you don't have ACPI or APM enabled in your kernel, TuxOnIce can't tell the hardware to power off, but if you reach a screen reading Ready to power down the suspend is complete and you can manually power off.

5.3 It resumes but hangs. I can't boot any more. Or, my machine reboots forever.

You have to tell kernel to ignore the resume partition using the noresume option. On the lilo prompt, type something like "linux noresume". You may find useful to have one of your lilo choices launch your kernel with the noresume option. You now have to figure out why it didn't work ;-) See the Troubleshooting section of the HOWTO.

5.4 Suspending and resuming takes ages, what can I do?

Using the suspend script, most of the delay is due to the necessity of stopping drivers before suspending and restarting them after resume. Suspending will never be as fast as you imagine it, at least as long as hardware drivers will not correctly handle suspending events.

If the delay is in writing to disk, then you may want to play with the image_size_limit option in /sys/power/suspend2/. By setting a maximum image size, TuxOnIce will try and free as much memory as possible to achieve this (or failing that, flushing to disk) which will speed up suspend and resume on machines with slow disk IO. The only downfall is that your machine might not be as responsive on resume until buffers and caches are restored.

If you are feeling daring, you can write your own customised suspend script, which does the minimum required for your machine. Some machines can suspend instantly simply by echo > /sys/power/suspend2/do_suspend. Others need a bit more of a hand - the big offenders are generally sound cards, network cards, PCMCIA and USB.

5.5 Can I switch from Windows to Linux using TuxOnIce?

Yes, but the result is guaranteed only if the linux and windows partitions are totally independant. If for instance you use a FAT partition to share data between the two operating systems, you must unmount the partition before suspending. Otherwise, modification of data under Windows may be lost when resuming Linux. Conversely, modification of data under Linux will be lost if Windows 2000's own software suspension feature is used.

Doug has posted the following message on the TuxOnIce mailing list concerning unmounting of drives in XP (not verified):

> It is posible, there is iirc something in disk manager about this, I 
> will pay about with my win2k box and see if I can find it, but I have 
> definatly seen something about it.
>
> http://support.microsoft.com/default.aspx?scid=KB;EN-US;q314449&
> might be the right sort of area
>
> -- 
>      Tim Fletcher                 


Actually that link looks dead on.  Run mountvol from the command line with
no parameters and you get a list of volume IDs (hideously long strings) and
locations where they are mounted and details on syntax for how to mount 
and unmount drives.  I've attached the screen output below.  
To automate it just go to 

http://www.budja.com/shutdown/

to get a simple little command-line program for hibernating and then write
yourself a little .bat file to put it all together.
Below is one I wrote but you'll need to run mountvol to get the right
volume ID to put in here first before using it and put the right path in
for the shutdown command.  Of course I don't know yet what exactly
"unmounting" means here. Does it really synchronize the disk or whatever
is needed? I'll let ya know how the actual results are when using this to
suspend in and out of windows and linux a few times.  Next I'll try to get
my "Easy Acess Buttons" programmed and maybe I'll even be able to
reprogram the power button.  If not it's not so bad to have to click a
link somewhere to hibernate.  Oh yeah... might as well add the A drive to
this procedure... I doubt it matters though seeing as how you can pull
idle floppy's out of windows without causing any harm anyway.

5.6 Can I change removable devices while suspended?

This can be done provided you stop the corresponding drivers before suspending. For this reason, it seems better to stop USB, PCMCIA and IrDA before suspending and start the services back on resume. Good precaution is also to unmount the floppy drive.

5.7 Suspension seems to occur correctly, but when I resume the suspend signature is not found.

Double check that you have correctly set a resume=swap:/dev/hdX option and that you have updated your lilo or grub configuration. Also check that you don't have an unwanted noresume option. If all this is OK than perhaps you have one of those disks with a flaky hardware cache. Try to use hdparm -W 0 /dev/hdX before suspending. This should disable hardware cache. Please report if you encounter this bug since it is supposed to be fixed since 2.4.18-beta8.

5.8 After resume, why is my clock at the time of suspension?

The system time is stored in a part of memory that is saved during suspension. One needs to reset the clock using hwclock upon resume, since reading the CMOS is the only way for the system to know the real time. Use the hibernate script in order to do that automatically.

This should also be done for you in recent 2.6 kernels.

5.9 How can I patch TuxOnIce to have a script launched on resume?

See the hibernate script documentation.

5.10 Suspension seems to occur correctly, but when I resume mouse and keyboard are frozen.

This seems to happen for some hardware configurations. We haven't found a proper way to fix that for the moment. Sometimes, it seems that stopping gpm before suspending and restarting it upon resume can help. In other cases, just stopping gpm and never restarting it is even better.

5.11 It fails to suspend with a message "not enough pages"

The amount of memory needed depends on a lot of things. For the average user, sizeof(RAM)x2 is ample for the swap partition used by TuxOnIce. With compression, you should usually be able to get away with 1/2 the amount of RAM you have.

If you're using the expected compression ratio, be careful not to set it too optimisticly.

5.12 How can I get Bootsplash to play with Software suspend nicely?

Bootsplash is no longer supported with TuxOnIce. The code base wasn't easy to work with, and better alternatives emerged - (see UserUI). The following exists for historical purposes only...

Documentation contributed by Alessandro Barbosa (barbosa_alessandro at hotmail dot com): Bootsplash and Suspend2 on Fedora Core 2

Or the following, thanks to Markus Gaugusch and Nigel Cunningham:

Bootsplash with software suspend still seems somewhat voodoo-ish, but hopefully the steps listed here will point you in the right direction.

1. Patch your kernel with the official bootsplash patch from www.bootsplash.org and read the documentation with it. Configure your kernel with bootsplash /proc support.
2. Install the splash utilities from bootsplash.org and a theme.
3. If you are using a version 1 or 2 bootsplash image, you will need to patch software suspend with the bootsplash-option patch in the Suspend2 package and recompile. With a version 3 bootsplash image, this is not neccesary.
4. On suspend, execute:

   /path/to/splash -s -u 62 /etc/bootsplash/themes/.../config/bootsplash-1024x768.cfg

   If you have a version 1 or 2 image, echo 424 582 506 30 15 > /proc/sys/kernel/splash_progress. These numbers are x-coordinate, y-coordinate, width, height and RGB colour (24-bit).

   This puts the splash screen on VT 63 (counting from 0), puts a black progress box roughly down the bottom.

5. Suspend.
6. On resume, execute splash -s -u 62 to clear the bootsplash again.
7. Possibly change VTs back to your original one.

5.13 Resuming complains about a version mismatch.

The noresume kernel command line option discards the suspend image and restores the swap signature. When using the noresume option, the suspended kernel state and filesystem state is lost. When using a journaling filesystem, no filesystem data is lost.

WARNING! Scenarios that can lead to data loss or corruption:

This may occur after suspending with a TuxOnIce-enabled kernel, then booting a different kernel.

Scenario 1 - a second kernel recognises the suspend image

The version mismatch is caused by attempting to resume a kernel whose header does not match the header of the suspended kernel in the suspend image.

For example, you suspended a kernel, and recompiled it, or you suspended one kernel and attempted to resume another one which recognizes the suspend image. In this case, put noresume on the command line for this boot.

Should you forget, you will get a version mismatch message: SHIFT to reboot, CONTROL to continue - push shift and either select the correct kernel or use the noresume option to boot.

Any difference between resumed and suspended kernels will corrupt/crash the system on forcing resume with CONTROL and possible cause filesystem damage as well.

Scenario 2 - a second kernel does not recognise the suspend image

This is described in detail in the HOWTO (Avoiding data loss).

5.14 Is there any way to convince TuxOnIce to free things like disk caches and buffers but nothing else?

Yes. Set the image_size_limit option to -2. This will get TuxOnIce to do the equivalent to echo 1 > /proc/sys/vm/drop_caches while preparing the image.

If you set the image_size_limit option to a positive value, TuxOnIce will attempt to free memory until the image size is less that the value in megabytes. Since disk caches are the easiest thing to free, the Linux VM will free it first. If you leave the value of image_size_limit at zero, it will only free as much memory as it needs to be able to suspend.

If you are using the hibernate script, you can add the line ImageSizeLimit nocache to adjust the image_size_limit to approximate dropping caches and buffers.

5.15 Freezer debugging: It hangs at 'Waiting for activity to finish' or 'Syncing remaining I/O'.

1. Compile in debugging support if you haven't already. You may also want to increase the size of the message buffer:
   • For 2.4, edit kernel/printk.c. Change 16384 on line 41 to a higher power of two, say 1048576
   • For 2.6, change the kernel log buffer size while choosing your compile options. It's under General Setup.
2. Set your debugging options as follows:
   • echo 1 > /sys/power/suspend2/user_interface/enable_escape - ensures you can press escape to cancel the suspend when it hangs
   • echo 1 > /sys/power/suspend2/user_interface/log_everything - tells TuxOnIce to record all it's about to display
   • echo 4 > /sys/power/suspend2/user_interface/default_console_level - tell it to display medium level debugging
   • echo 2 > /sys/power/suspend2/user_interface/debug_sections - tell it to display messages about the freezer
3. Tell it to try to suspend: echo > /sys/power/suspend2/do_suspend
4. When it hangs (assuming it does), press escape. It should print a lot of information and then return you to the command prompt.
5. Look in /var/log/messages. If the output does not contain the names of procedures, but instead lots of hexadecimal numbers, run the output through ksymoops. (See Documentation/oops-tracing in the kernel tree for more help here).
6. Send your output directly to Nigel, who will usually get back to you pretty quickly. Don't send all of the output to the list, please.

5.16 I've suspended and resumed and now I can't open new X applications and my /tmp directory is empty (on Debian)

A recent version of the initscripts package decided to blow away temporary directories when calling mountnfs.sh (See Bug #227112). The simple solution is to remove mountnfs.sh from your SWSUSP_STOP_SERVICES_BEFORE_SUSPEND in /etc/suspend.conf and add your extra NFS mounts into SWSUSP_UMOUNTS.

Alternately, upgrade to the new hibernate script which does not call the init script in question.

5.17 On resume, you get a "BIG FAT WARNING!! Failed to translate the device name into a device id."

This can happen for several reasons:

• A misspelt resume= option on your kernel command line.
• You are using an initrd, and IDE support is built as modules and the modules are not loaded yet. Load the IDE modules before calling the resume process in the initrd.
• You are using an initrd, and it does not contain a /sys/ directory.

5.18 My system hibernates but doesn't even try to resume.

If you're using an initrd or initramfs, you _MUST_ have a line in it telling TuxOnIce when to try to resume. This needs to be done before mounting any filesystems that were mounted when you hibernated, but after setting up access to anything TuxOnIce will need in order to resume (lmsetup etc). Note that if you hibernated to a swap file or ordinary file, you still don't need to mount the filesystem. Please also note that in the case of swap storage, every swap device needs to be accessible. Your image could have been stored on any combination of the devices that were swapon'd when you hibernated (which ones depends on a combination of what swap was in use, swap priorities assigned at swapon time and the amount of data written to disk).

5.19 System hangs on booting a TuxOnIce kernel (2.6)

If CONFIG_CC_OPTIMIZE_FOR_SIZE is enabled, you may get a hang on boot just after:

TuxOnIce 2.2.10.2, with support for usm, compression, swap storage, file storage, userui.
TuxOnIce: Normal swapspace found.

5.20 It suspends twice every time I hit the power button!

Your power button is probably sending two events every time you push it (sometimes one for depressing it, one for releasing it, sometimes just two events). You can tell acpid only to react to one event my editing your /etc/acpi/events/powerbtn file to contain "event=button[ /]power.*[02468ace]$" instead of the default event= line. This tells it to only respond to every second power button event.

5.21 It hangs when "Copying original kernel back"

See the HOWTO.

5.22 It hangs when "Reading caches" and I have a Toshiba laptop

This should be fixed since Suspend2 2.1.8.12.

5.23 Why is having a filesystem mounted at resume-time dangerous?

The saved image of your kernel is intimately linked with the state of the filesystems that were mounted when you suspended. The kernel expects that it will be the only thing that can modify the filesystem whilst it is mounted. If between suspending and resuming your machine you mount a filesystem that was mounted in the suspended image, you will change its internal state (even if you don't modify any files). In particular, simply mounting a journalled filesystem read-only will replay the filesystem's journal, causing the state of the filesystem to be inconsistent with what the suspended image thinks it is.

If a filesystem has been modified in the slightest, then resuming your suspended kernel will most likely cause corruption of the filesystem. This commonly occurs when people mount their root fs in their initrd, which is why the sanity check for mounted filesystems is there.

In short, don't mount or touch filesystems that are mounted in the suspend image before resuming. A couple of people have lost their data this way.

5.24 UserUI: I get "FBIOSPLASH_SETSTATE failed: error code 22" when using the suspend2ui_fbsplash

This just means you haven't patched your kernel with fbsplash, which is not required anyway. (If you do patch your kernel, you can also get prettier verbose screens, but it's not required for just the progress bar). The error message should be taken out in a future version.

5.25 When suspending it fails with "Failed to initialise the compression transform"

The default hibernate configuration will try to use the lzf compressor. If the compressor is not available, you will get this error. You need to recompile your kernel with CONFIG_CRYPTO_LZF=y.

Another cause is that hibernate 1.09 had an incompatibility with mawk, so that it would not set the compressor at all, giving this error. Solution is to use gawk or upgrade to hibernate 1.10.

If you are using your own custom suspend script, you need to set the compressor/encryptor settings in /sys/power/suspend2 appropriately, or echo 0 > /sys/power/suspend2/compression/enabled and/or encryption/enabled if you don't want to use compression/encryption.

The available compressor/encryptors are listed in /proc/crypto.