Bug 55838

This occurs for me also using regular suspend (not suspend-to-disk).  The
machine is a Dell Latitude CPxJ.

Same problem here on an IBM A21P and A22P... Any BIOS APM event seems to kill
the laptop completly leaving only weird framebuffer pixels on the display.

I have not tested the ext2-3 change, but I am running ext3 on both systems.

This email is about a possible workaround.

I had the same problems with RH7.2 on a Dell CPx H500GT, while suspend worked
wonderfully with RH7.1. 

More recently, I have read on the news (a mail from Kamil Iskra on the kernel
mailing lists) that the 'noatime' mount option for the "/" (root) ext3
filesystem makes suspend to disk work again (i.e. type 'mount / -o
remount,noatime and try to suspend).

And indeed, it works again! Note that I use this option only for the root
filesystem. E.g. "/home" is not mounted with 'noatime'. (I have only /home /boot
and / partitions for linux).

Now, my question is: what functionality do we loose with this workaround? What
is the proper recording of atimes important for ?

The noatime trick doesn't work here.  Making / ext2 does work, however.  No
other partitions need to be changed.

Good call Bernard, Works on my A21P! I will try a A22P as well next week...

I am also curious what the role of atime is.

If I am correct, the atime is the last write OR READ access time. So every time
you read a file, its atime is updated (i.e. you make a write access to the disk
to update its atime entry, if the disk is mounted R/W).

You can list the atime of a file with 'ls -l --time=atime'. So 'noatime' means
that this entry is not updated any more.

I think the atime entry is used to clean up the /tmp directory. Each file that
has not been accessed (i.e. read or written) in the last week is removed by
tmpwatch.

Otherwise, I don't think updating regularly this entry is very useful. (Anyone
correct me if I am wrong, please).

So to avoid loosing any functionality, the best is maybe to put /tmp on a
separate partition in either ext2 or ext3.

This problem may be hardware- or BIOS-related.  I had the Latitude CPxJ for
which the above workaround didn't work.  I recently replaced that with a
Latitude C610 that doesn't have the problem at all--even if / is ext3, it
suspends and resumes just fine (except for the onboard NIC, but that's another
bug...).  The C610 is running the rawhide kernel and XFree86 4.2, but it
suspended and resumed just fine with the stock and up2date kernels and no X as well.

Unfortunately, I won't have access to the CPxJ to test any fixes, so so long and
good luck.

Arjan, any ideas on this one?

This sort of problem is normally due to the fact that ext2 and ext3 just have
different timings.  ext3 is a bit more careful about writing data (that's the
whole point!), and it normally starts flushing data to disk earlier than ext2
would.  So, if the apm cycle starts the apm script timestamps get updated, ext3
is more likely to touch the disk earlier than ext2, and that can cause the bios
to think that the system is not idle so suspend fails.

There _may_ be a kernel problem involved too --- there were some changes in apm
in more recent kernels which make this sort of interaction less likely.  Could
you try a rawhide kernel and see if that helps?