Bug 55838 - apm suspend-to-disk trouble with RH7.2 using ext3 filetype
apm suspend-to-disk trouble with RH7.2 using ext3 filetype
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Stephen Tweedie
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-07 11:27 EST by Patrick Guio
Modified: 2007-04-18 12:38 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-26 17:12:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Patrick Guio 2001-11-07 11:27:05 EST
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!
Comment 1 Matthew Saltzman 2001-11-27 14:39:47 EST
This occurs for me also using regular suspend (not suspend-to-disk).  The
machine is a Dell Latitude CPxJ.
Comment 2 Greg Kurtzer 2001-11-30 19:17:02 EST
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.
Comment 3 Need Real Name 2001-12-08 06:54:32 EST
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 ?
Comment 4 Matthew Saltzman 2001-12-08 21:41:42 EST
The noatime trick doesn't work here.  Making / ext2 does work, however.  No
other partitions need to be changed.
Comment 5 Greg Kurtzer 2001-12-10 00:11:11 EST
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.
Comment 6 Need Real Name 2001-12-10 04:00:37 EST
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.
Comment 7 Matthew Saltzman 2002-02-04 22:52:23 EST
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.
Comment 8 Bernhard Rosenkraenzer 2002-02-26 12:49:41 EST
Arjan, any ideas on this one?
Comment 9 Stephen Tweedie 2002-02-26 13:36:47 EST
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?

Note You need to log in before you can comment on or make changes to this bug.