Red Hat Bugzilla – Bug 55838
apm suspend-to-disk trouble with RH7.2 using ext3 filetype
Last modified: 2007-04-18 12:38:05 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.17-14 i686) Description of problem: I have upgraded my laptop from 7.1 to 7.2 recently and there is a problem with the suspend to disk function of APM when migrating to ext3 support. The suspend to disk function does not work any longer! I set up the HD partitions to ext2 support (by editing /etc/fstab, running mkinitrd and rebooting) and the suspend to disk function works nicely again! Note that I have the last kernel-2.4.9-13 and the apmd-30final-34. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Running ext3 filetype with journalling on a laptop Close the screen of the laptop Actual Results: The computer does do a suspend to disk, the led that indicates power does not light down and the computer still runs...... Expected Results: The computer should do a suspend to disk, the led that indicates power should turned off and there should not be any activity until the computer is waken up again by reopening the screen Additional info: The problem is solved by going back to ext2 filetype!
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?