Hi,
Kernel 2.4.15 has problems with APM suspend if ext3 filesystem is compiled
into the kernel.
I noticed the problems on my just acquired Compaq Armada E500 notebook.
The problem was also there with kernel 2.4.14 + ext3 patch. BUT I am
almost sure that it worked fine on my old Compaq Armada 7800 with the same
2.4.14 + ext3, so the problem might in some way be influenced by the
hardware/BIOS/whatever.
The problem is that, when I press the suspend button on the laptop or when
I invoke "apm -s", the screen blanks, but the laptop doesn't suspend.
After a second or two I get an error beep and the screen is back on again.
In the kernel log I get "User suspend" from "apmd", followed by "kernel:
apm: suspend: Unable to enter requested state", followed by "Normal
resume" from "apmd". "apm -s" returns with "Input/output error" (EIO) in
this case. The chance of a successful suspend is non-zero, but rather
small, I would say less than 10%. Appending "apm=debug" on the kernel
commandline doesn't seem to add any useful info.
I've been starting my system (RedHat 7.2 on i686) in the single user mode,
starting just syslogd and apmd, but that doesn't help. Neither does
changing the filesystem type back to ext2 in /etc/fstab: kjournald is
still started and the problem still occurs. What does help is recompiling
the kernel without ext3: as soon as this happens, I get a 100% success
rate with suspends, either in single user mode or with all the daemons and
X running. Just loading the ext3 into the kernel with "modprobe ext3"
doesn't seem to negatively affect it in that case, my guess would be that
that's due to kjournald not being started.
I tried to locate others with such problems via Google, and with some
success, although I can't be entirely sure that the reason for their
problems is the same as mine, of course. Some examples would be:
http://marc.theaimsgroup.com/?l=linux-kernel&m=100444185918459&w=2
http://groups.google.com/groups?hl=en&selm=9t28me%2416i6h0%241%40ID-106838.news.dfncis.de
http://groups.google.com/groups?q=apm+ext3&hl=en&rnum=1&selm=Pine.LNX.4.30.0111071331010.26250-100000%40fyspc-rp18.uio.no
So the problem does seem to be known among some, but somehow I couldn't
find a clear report in the linux-kernel archives about the issue. Hence
this email.
If you reply, please Cc to me, as I'm not on the list.
Regards,
--
Kamil Iskra http://www.science.uva.nl/~kamil/
Section Computational Science, Faculty of Science, Universiteit van Amsterdam
[email protected] tel. +31 20 525 75 35 fax. +31 20 525 74 90
Kruislaan 403 room F.202 1098 SJ Amsterdam The Netherlands
Kamil,
thank you for the clear and convincing problem description.
It's becoming increasingly clear that we need to do something with
ext3 and laptops.
I don't understand what can be causing the behaviour which you
report. Presumably, some application is generating disk writes,
and kjournald is thus performing disk IO every five seconds.
But I don't know why this should prevent the machine from suspending,
nor why it's different with other filesystems.
If possible, could you please edit fs/jbd/journal.c and change
journal->j_commit_interval = (HZ * 5);
to
journal->j_commit_interval = (HZ * 30);
Thanks.
Kamil Iskra wrote:
>
> Hi,
>
> Kernel 2.4.15 has problems with APM suspend if ext3 filesystem is compiled
> into the kernel.
>
> I noticed the problems on my just acquired Compaq Armada E500 notebook.
> The problem was also there with kernel 2.4.14 + ext3 patch. BUT I am
> almost sure that it worked fine on my old Compaq Armada 7800 with the same
> 2.4.14 + ext3, so the problem might in some way be influenced by the
> hardware/BIOS/whatever.
>
> The problem is that, when I press the suspend button on the laptop or when
> I invoke "apm -s", the screen blanks, but the laptop doesn't suspend.
> After a second or two I get an error beep and the screen is back on again.
> In the kernel log I get "User suspend" from "apmd", followed by "kernel:
> apm: suspend: Unable to enter requested state", followed by "Normal
> resume" from "apmd". "apm -s" returns with "Input/output error" (EIO) in
> this case. The chance of a successful suspend is non-zero, but rather
> small, I would say less than 10%. Appending "apm=debug" on the kernel
> commandline doesn't seem to add any useful info.
>
> I've been starting my system (RedHat 7.2 on i686) in the single user mode,
> starting just syslogd and apmd, but that doesn't help. Neither does
> changing the filesystem type back to ext2 in /etc/fstab: kjournald is
> still started and the problem still occurs. What does help is recompiling
> the kernel without ext3: as soon as this happens, I get a 100% success
> rate with suspends, either in single user mode or with all the daemons and
> X running. Just loading the ext3 into the kernel with "modprobe ext3"
> doesn't seem to negatively affect it in that case, my guess would be that
> that's due to kjournald not being started.
>
> I tried to locate others with such problems via Google, and with some
> success, although I can't be entirely sure that the reason for their
> problems is the same as mine, of course. Some examples would be:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=100444185918459&w=2
> http://groups.google.com/groups?hl=en&selm=9t28me%2416i6h0%241%40ID-106838.news.dfncis.de
> http://groups.google.com/groups?q=apm+ext3&hl=en&rnum=1&selm=Pine.LNX.4.30.0111071331010.26250-100000%40fyspc-rp18.uio.no
>
> So the problem does seem to be known among some, but somehow I couldn't
> find a clear report in the linux-kernel archives about the issue. Hence
> this email.
>
> If you reply, please Cc to me, as I'm not on the list.
>
> Regards,
>
> --
> Kamil Iskra http://www.science.uva.nl/~kamil/
> Section Computational Science, Faculty of Science, Universiteit van Amsterdam
> [email protected] tel. +31 20 525 75 35 fax. +31 20 525 74 90
> Kruislaan 403 room F.202 1098 SJ Amsterdam The Netherlands
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton wrote:
>
> Kamil,
>
> thank you for the clear and convincing problem description.
>
> It's becoming increasingly clear that we need to do something with
> ext3 and laptops.
My Dell Latitude CPx J750GT running RH7.2 and all-ext3 (except
for my Oracle 9012 database partition) suspends just fine by
hitting Fn-Suspend without doing anything special. Has been
working forever and moving to ext3 (built in kernel) hasn't
changed anything. Resume also works fine - recent log:
Nov 25 20:43:19 dolphin cardmgr[766]: executing: './network suspend xircom_tulip_cb'
Nov 25 20:43:19 dolphin kernel: xircom_suspend(eth0)
Nov 25 20:43:20 dolphin modprobe: modprobe: Can't locate module irlan0
Nov 25 20:43:20 dolphin apmd[704]: User Suspend
Nov 25 23:55:27 dolphin kernel: xircom_remove_one(eth0)
Nov 25 23:55:27 dolphin kernel: tty04 unloaded
Nov 25 23:55:27 dolphin cardmgr[766]: shutting down socket 0
Nov 25 23:55:27 dolphin cardmgr[766]: executing: './network stop xircom_tulip_cb'
Nov 25 23:55:27 dolphin cardmgr[766]: stop cmd exited with status 1
Nov 25 23:55:27 dolphin cardmgr[766]: executing: 'modprobe -r xircom_cb'
Nov 25 23:55:27 dolphin cardmgr[766]: executing: 'modprobe -r cb_enabler'
Nov 25 23:55:27 dolphin kernel: cs: cb_free(bus 2)
Nov 25 23:55:27 dolphin kernel: cs: cb_alloc(bus 2): vendor 0x115d, device 0x0003
Nov 25 23:55:27 dolphin kernel: PCI: Enabling device 02:00.0 (0000 -> 0003)
Nov 25 23:55:27 dolphin kernel: PCI: Setting latency timer of device 02:00.0 to 64
Nov 25 23:55:27 dolphin kernel: eth0: Xircom Cardbus Adapter rev 3 at 0x4000, 00:10:A4:F9:19:A0, IRQ 11.
Nov 25 23:55:27 dolphin kernel: eth0: MII transceiver #0 config 3100 status 7809 advertising 01e1.
Nov 25 23:55:27 dolphin kernel: PCI: Enabling device 02:00.1 (0000 -> 0003)
Nov 25 23:55:27 dolphin /etc/hotplug/pci.agent: ... no drivers for PCI slot
Nov 25 23:55:27 dolphin cardmgr[766]: initializing socket 0
Nov 25 23:55:27 dolphin cardmgr[766]: socket 0: Xircom CBEM56G-100 CardBus 10/100 Ethernet + 56K Modem
Nov 25 23:55:27 dolphin kernel: ttyS04 at port 0x4080 (irq = 11) is a 16550A
Nov 25 23:55:27 dolphin kernel: xircom_resume(eth0)
Nov 25 23:55:28 dolphin /etc/hotplug/pci.agent: ... no drivers for PCI slot
Nov 25 23:55:28 dolphin cardmgr[766]: executing: 'modprobe cb_enabler'
Nov 25 23:55:28 dolphin cardmgr[766]: executing: 'modprobe xircom_cb'
Nov 25 23:55:28 dolphin cardmgr[766]: executing: './network start xircom_tulip_cb'
Nov 25 23:55:28 dolphin sysctl: net.ipv4.ip_forward = 0
Nov 25 23:55:28 dolphin sysctl: net.ipv4.conf.default.rp_filter = 1
Nov 25 23:55:28 dolphin sysctl: kernel.sysrq = 1
...etc, etc...
> I don't understand what can be causing the behaviour which you
> report. Presumably, some application is generating disk writes,
> and kjournald is thus performing disk IO every five seconds.
> But I don't know why this should prevent the machine from suspending,
> nor why it's different with other filesystems.
[asuardi@dolphin asuardi]$ mount
/dev/hda8 on / type ext3 (rw,noatime)
none on /proc type proc (rw)
/dev/hda2 on /vmware type ext3 (rw,noatime)
/dev/hda3 on /oradata type ext2 (rw,noatime)
/dev/hda6 on /share type ext3 (rw,noatime)
none on /dev/pts type devpts (rw,gid=5,mode=620)
none on /dev/shm type tmpfs (rw)
> If possible, could you please edit fs/jbd/journal.c and change
>
> journal->j_commit_interval = (HZ * 5);
> to
> journal->j_commit_interval = (HZ * 30);
>
> Thanks.
>
> Kamil Iskra wrote:
> >
> > Hi,
> >
> > Kernel 2.4.15 has problems with APM suspend if ext3 filesystem is compiled
> > into the kernel.
> >
> > I noticed the problems on my just acquired Compaq Armada E500 notebook.
> > The problem was also there with kernel 2.4.14 + ext3 patch. BUT I am
> > almost sure that it worked fine on my old Compaq Armada 7800 with the same
> > 2.4.14 + ext3, so the problem might in some way be influenced by the
> > hardware/BIOS/whatever.
> >
> > The problem is that, when I press the suspend button on the laptop or when
> > I invoke "apm -s", the screen blanks, but the laptop doesn't suspend.
[snipped problem description]
--alessandro
"we live as we dream alone / to break the spell we mix with the others
we were not born in isolation / but sometimes it seems that way"
(R.E.M., live intro to 'World Leader Pretend')
On Tue, 2001-11-27 at 15:32, Alessandro Suardi wrote:
> Andrew Morton wrote:
> >
> > Kamil,
> >
> > thank you for the clear and convincing problem description.
> >
> > It's becoming increasingly clear that we need to do something with
> > ext3 and laptops.
>
> My Dell Latitude CPx J750GT running RH7.2 and all-ext3 (except
> for my Oracle 9012 database partition) suspends just fine by
> hitting Fn-Suspend without doing anything special. Has been
> working forever and moving to ext3 (built in kernel) hasn't
> changed anything. Resume also works fine - recent log:
as does my ThinkPad T-21. calling apm --suspend works fine. Though for
some reason if I leave it on all night (not suspended) I wake up to a
frozen laptop. Not exactly sure why, perhaps ext3 related, not exactly
sure how to investigate.
shaya
On Tue, 27 Nov 2001, Andrew Morton wrote:
> I don't understand what can be causing the behaviour which you
> report. Presumably, some application is generating disk writes,
> and kjournald is thus performing disk IO every five seconds.
The only such "application" could be syslogd or apmd. There is virtually
nothing more running in single user mode.
> If possible, could you please edit fs/jbd/journal.c and change
>
> journal->j_commit_interval = (HZ * 5);
> to
> journal->j_commit_interval = (HZ * 30);
Just tried it. Unfortunately, it didn't improve anything. Consistent
failure what doing "apm -s". I tried some 15 times or so in single user
mode.
Should you, or anybody else, have further suggestions, I'll be happy to
try them out.
--
Kamil Iskra http://www.science.uva.nl/~kamil/
Section Computational Science, Faculty of Science, Universiteit van Amsterdam
[email protected] tel. +31 20 525 75 35 fax. +31 20 525 74 90
Kruislaan 403 room F.202 1098 SJ Amsterdam The Netherlands
Kamil Iskra wrote:
>
> On Tue, 27 Nov 2001, Andrew Morton wrote:
>
> > I don't understand what can be causing the behaviour which you
> > report. Presumably, some application is generating disk writes,
> > and kjournald is thus performing disk IO every five seconds.
>
> The only such "application" could be syslogd or apmd. There is virtually
> nothing more running in single user mode.
>
> > If possible, could you please edit fs/jbd/journal.c and change
> >
> > journal->j_commit_interval = (HZ * 5);
> > to
> > journal->j_commit_interval = (HZ * 30);
>
> Just tried it. Unfortunately, it didn't improve anything. Consistent
> failure what doing "apm -s". I tried some 15 times or so in single user
> mode.
>
> Should you, or anybody else, have further suggestions, I'll be happy to
> try them out.
I'm stumped. Sorry. I was hoping Alan would leap in with
words of revelation.
Maybe you can turn on APM debugging with `apm=debug' on the
LILO command line, or `modprobe apm debug=1', see if that
provides a hint. APM debug mode doesn't seem to do much though.
-
On Thu, 29 Nov 2001, Mark Hahn wrote:
[This is in response to a private email - I'm posting to the list because
of significant results]
> > > are your filesystems mounted with noatime/nodiratime?
No, they (or it rather, for I have just one) were mounted with default
options.
Following Mark's suggestion, I remounted my filesystem with noatime,
and... suspends suddenly started succeeding. nodiratime didn't seem to
matter, noatime was enough. The success rate was very good, I don't think
I've seen even a single suspend failure.
So, now I know a workaround, which for me as a user is already quite
significant, but that's not really a proper fix, right?
I looked at the apm script, in RedHat 7.2 it sits in
/etc/sysconfig/apm-scripts/apmscript and is >10K. Its behaviour is
controlled by /etc/sysconfig/apmd. I already had most things turned off
there, for I just don't need them all, but due to some omision I still had
"NETFS_RESTART" on (which attempts to unmount remote filesystem on suspend
and mount them on resume -- which doesn't matter for me since I don't
mount any remote filesystems). Anyway, I commented out that
"NETFS_RESTART" and suddenly I started getting successful suspends even
with the default filesystem options, i.e. _with_ atime. However, the
success rate was not impressive, it seemed to be higher in general for
"apm -s" than for the suspend button in the machine. The success rate in
that case is significantly improved if one invokes sync(1) a few seconds
before attempting a suspend. In fact, suspends seem to be quite reliable
when performed this way.
If I may, I would like to make some purely user-level speculation (I don't
know how all this stuff works internally). I've long since known that the
suspends are not completely reliable, even with ext2, particularly if
there was some disk activity going to right before or during a suspend.
So I knew for example that trying to suspend a laptop with xmms playing
some mp3s off the hard-disk would usually fail -- I had to pause the
playback and only then press the suspend button. So, it is not that the
problem with ext3 is necessarily new -- it might be a manifestation of the
same problem as before, only in a more apparent form, perhaps because of a
more synchronous disk access needed for the journal. Perhaps it's not even
a bug, but just the way things work with suspend -- perhaps it simply
can't be performed reliably when there is a disk activity going on.
Although personally, I would of course hope that it is just a bug that can
be fixed and result in rock-solid suspends succeeding every time, even in
the middle of kernel recompilation :-).
--
Kamil Iskra http://www.science.uva.nl/~kamil/
Section Computational Science, Faculty of Science, Universiteit van Amsterdam
[email protected] tel. +31 20 525 75 35 fax. +31 20 525 74 90
Kruislaan 403 room F.202 1098 SJ Amsterdam The Netherlands
On Wed, 28 Nov 2001, Andrew Morton wrote:
> Maybe you can turn on APM debugging with `apm=debug' on the
> LILO command line, or `modprobe apm debug=1', see if that
> provides a hint. APM debug mode doesn't seem to do much though.
Yes, exactly. I've already tried it before, but it didn't give me any
useful clue. Anyway, you can find the output below.
With kjournald (ext3):
Nov 30 22:38:27 bubu kernel: apm: setting state busy
Nov 30 22:38:28 bubu kernel: apm: setting state busy
Nov 30 22:38:28 bubu apmd[285]: User Suspend
Nov 30 22:38:28 bubu kernel: apm: setting state busy
Nov 30 22:38:28 bubu kernel: apm: setting state busy
Nov 30 22:38:29 bubu kernel: apm: suspend: Unable to enter requested state
Nov 30 22:38:30 bubu apmd[285]: Normal Resume after 00:00:02 (100% unknown) AC power
Nov 30 22:38:34 bubu kernel: apm: setting state busy
Nov 30 22:38:34 bubu apmd[285]: User Suspend
Nov 30 22:38:34 bubu kernel: apm: setting state busy
Nov 30 22:38:34 bubu kernel: apm: setting state busy
Nov 30 22:38:35 bubu kernel: apm: suspend: Unable to enter requested state
Nov 30 22:38:36 bubu apmd[285]: Normal Resume after 00:00:02 (100% unknown) AC power
Without kjournald (ext2):
Nov 30 22:41:04 bubu kernel: apm: setting state busy
Nov 30 22:41:04 bubu apmd[283]: User Suspend
Nov 30 22:41:26 bubu kernel: apm: received normal resume notify
Nov 30 22:41:26 bubu kernel: apm: received power status change notify
Nov 30 22:41:27 bubu apmd[283]: Normal Resume after 00:00:23 (100% unknown) AC power
Nov 30 22:41:36 bubu kernel: apm: setting state busy
Nov 30 22:41:36 bubu kernel: apm: setting state busy
Nov 30 22:41:37 bubu apmd[283]: User Suspend
Nov 30 22:41:37 bubu kernel: apm: setting state busy
Nov 30 22:41:58 bubu kernel: apm: received normal resume notify
Nov 30 22:41:58 bubu kernel: apm: received power status change notify
Nov 30 22:41:59 bubu apmd[283]: Normal Resume after 00:00:22 (100% unknown) AC power
--
Kamil Iskra http://www.science.uva.nl/~kamil/
Section Computational Science, Faculty of Science, Universiteit van Amsterdam
[email protected] tel. +31 20 525 75 35 fax. +31 20 525 74 90
Kruislaan 403 room F.202 1098 SJ Amsterdam The Netherlandsc
Kamil Iskra wrote:
>
> I've long since known that the
> suspends are not completely reliable, even with ext2, particularly if
> there was some disk activity going to right before or during a suspend.
Yup. It seems that your BIOS is being asked to suspend all devices
while there is still disk IO being performed. And it refuses to
suspend because the disk is still active.
The patch I sent you attempts to put a one-seond delay in the
APM suspend function before calling into the BIOS. That _should_
improve your suspend success rate, but there's really not much we
can do to prevent disk IO from being started at any time.
-
Hi!
> thank you for the clear and convincing problem description.
>
> It's becoming increasingly clear that we need to do something with
> ext3 and laptops.
>
> I don't understand what can be causing the behaviour which you
> report. Presumably, some application is generating disk writes,
> and kjournald is thus performing disk IO every five seconds.
> But I don't know why this should prevent the machine from suspending,
> nor why it's different with other filesystems.
Disk writes should not prevent suspend... unless he has buggy apm bios.
But I can not imagine bug doing _that_...
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi,
On Fri, Nov 30, 2001 at 03:59:03PM -0800, Andrew Morton wrote:
> Kamil Iskra wrote:
> >
> > I've long since known that the
> > suspends are not completely reliable, even with ext2, particularly if
> > there was some disk activity going to right before or during a suspend.
>
> Yup. It seems that your BIOS is being asked to suspend all devices
> while there is still disk IO being performed. And it refuses to
> suspend because the disk is still active.
Yep. I'd still like to know exactly what the circumstances around
this are: just what are the constraints which apm requires us to
observe for successful suspend? I've never had a laptop fail to
suspend due to this sort of problem with ext3, so it's obviously
different from one apm implementation to the next.
Cheers,
Stephen
On Wed, 5 Dec 2001, Stephen C. Tweedie wrote:
> > Yup. It seems that your BIOS is being asked to suspend all devices
> > while there is still disk IO being performed. And it refuses to
> > suspend because the disk is still active.
> Yep. I'd still like to know exactly what the circumstances around
> this are: just what are the constraints which apm requires us to
> observe for successful suspend? I've never had a laptop fail to
> suspend due to this sort of problem with ext3, so it's obviously
> different from one apm implementation to the next.
I tried to perform some more experiments yesterday to get some insight,
but I didn't get much further than before.
Basically, the conclussions that I reached are that for a reasonably
reliable suspend, I either need the filesystem to be mounted as ext2, or I
need "noatime" option with ext3. That's with 2.4.16 kernel BTW. In
either of the two configurations I don't seem to need to play with "sync"
or such before attempting a suspend: it mostly "just works".
I also ran a fairly disk-intensive "find /usr" in another xterm and tried
to suspend with this process running. With either of ext2 or
ext3+noatime, suspend attempts _sometimes_ succeed in this case, with a
rate of 30-50%, I think. That seems to be consistent with my past
experience with older Compaq Armada laptops, such as 15xx and 7xxx series.
Also, strangely enough, the success rate of suspends is higher if I invoke
"apm -s" from an xterm than when I do it from a virtual console. I'm
talking about identical situations here, same processes running and all,
with one root session in an xterm and another on the console and just
switching between them with Alt+Fn. I made so many tries and reboots that
I am quite certain that I'm not imagining this one.
With ext3 without noatime, suspend attempts occassionally succeed from
xterm, and practically never do from the virtual console. Manually
invoking "sync" doesn't seem to help.
I've also played with the configuration of syslogd, putting a '-' in front
of all file/device fields so as to prevent a sync, and with hdparm,
turning off various optimisations such as 32-bit I/O, DMA and more.
These changes didn't seem to matter.
I'm always willing to try some patches or other ideas which would allow a
seemless work of ext3 on my laptop. For the time being, I will probably
settle for ext3+noatime. The latter is not a stupid thing anyway if you
ever want your harddisk to spin down.
Regards,
--
Kamil Iskra http://www.science.uva.nl/~kamil/
Section Computational Science, Faculty of Science, Universiteit van Amsterdam
[email protected] tel. +31 20 525 75 35 fax. +31 20 525 74 90
Kruislaan 403 room F.202 1098 SJ Amsterdam The Netherlands