Bug 244177 - Reading /proc/apm slows down system clock
Reading /proc/apm slows down system clock
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
All Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-14 08:33 EDT by nvwarr
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-02 11:01:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output from dmidecode (8.51 KB, text/plain)
2007-10-01 01:20 EDT, nvwarr
no flags Details

  None (edit)
Description nvwarr 2007-06-14 08:33:44 EDT
executing:
cat /proc/apm
frequently causes system clock to slow down. Ntp is then unable to synchronize
properly. Since hald does this every two seconds, it causes the system clock to
go haywire.

Version-Release number of selected component (if applicable):

kernel-2.6.21-1.3194.fc7
kernel-2.6.21-1.3228.fc7
and probably others...

How reproducible:

Always

Steps to Reproduce:
1. Stop hald, as hald reads /proc/apm.
2. Then the clock should run normally.
3. while cat /proc/apm ; do : ; done
4. Leave it running a bit then CTRL-C
5. Clock should now be slowed.
  
Actual results:
reading /proc/apm frequently slows down the system clock

Expected results:
clock should run normally.

Additional info:
Since hald reads /proc/apm every 2 seconds, the system time is unusable. It runs
about 6 % too slow, but also with a large jitter. Even with ntp running, ntp is
not able to keep the system synchronized because of the large jitter.

I notice that this problem has been reported before a long time ago with a
really old kernel.
http://www.ussg.iu.edu/hypermail/linux/kernel/0012.3/0282.html

Perhaps this should be considered a security issue, because it allows a
non-privileged user to slow down the system clock.
Comment 1 Michael Schwendt 2007-07-26 07:33:13 EDT
Confirmed.

My system clock started losing a few seconds every minute
since I boot with acpi=off.
Comment 2 Michael Schwendt 2007-07-27 09:58:55 EDT
> http://www.ussg.iu.edu/hypermail/linux/kernel/0012.3/0282.html

That thread reads like a WONTFIX.

As another side-effect of hald polling apm so often, X output is
disturbed, too. For example, tvtime flickers approx. every two
seconds, which is very visible with e.g. stock quotes and news
scroll-lines.
Comment 3 nvwarr 2007-08-02 03:59:14 EDT
(In reply to comment #2)
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0012.3/0282.html
> 
> That thread reads like a WONTFIX.
> 
> As another side-effect of hald polling apm so often, X output is
> disturbed, too. For example, tvtime flickers approx. every two
> seconds, which is very visible with e.g. stock quotes and news
> scroll-lines.

After a bit more research, I have found that this seems to be a BIOS bug.
Looking at the source code in apm.c, I can see that there are a lot of
workarounds for various different buggy BIOSes, but not for mine.

My BIOS is:
Vendor          "American Megatrends Inc."
Version         "62710"
Date            "07/15/97"

However, the same problem might exist with other versions.

Adding "apm=off" to the kernel command line, disables apm and, of course, that
gets rid of the symptoms. Adding "apm=allow_ints" does _not_ solve the problem.

Perhaps a BIOS upgrade might solve the problem, but I haven't been able to find
one for my mainboard.



Comment 4 Christopher Brown 2007-09-16 17:55:53 EDT
Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel? If you know the model
number and manufacturer of your mainboard I may be able to track down a BIOS update.

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

Cheers
Chris
Comment 5 nvwarr 2007-09-28 03:17:56 EDT
Sorry to take so long to get back to you.

The problem persists with the 2.6.22.5-76.fc7 kernel.

I found an update for the BIOS in the end and flashed it, but that didn't fix
the problem either. So I am still having to use the workaround of not reading
/proc/apm (I've patched my version of hal so it doesn't read it either).

The motherboard is a Gigabyte GA-7ZX. Rev 1.01. The update seems to improve USB
support, but not much else. I got the update from gigabyte's website so I assume
it is the most recent one.
Comment 6 Christopher Brown 2007-09-29 15:11:38 EDT
Could you run the following:

# dmidecode (you may need to install this)

and attach the output as text/plain type to this bug.

I take it you are using APM because ACPI is unsupported by your system or the
kernel implementation fails for you - is this correct?
Comment 7 nvwarr 2007-10-01 01:20:25 EDT
Created attachment 212051 [details]
Output from dmidecode
Comment 8 nvwarr 2007-10-01 01:28:42 EDT
(In reply to comment #7)
> Created an attachment (id=212051) [edit]
> Output from dmidecode
> 

I forgot to mention one thing: the BIOS does support ACPI, but the kernel choses
to ignore this with the message "ACPI: BIOS age (1997) fails cutoff (1999),
acpi=force is required to enable ACPI". Interestingly, this is still the case
even after I flashed the BIOS, even thought at boot up, the "new" BIOS claims to
be from 2002.

With acpi=force, of course, /proc/apm is simply not there and the problem is
nicely swept under the carpet. I must admit, I had never tried this before, as I
had been warned that acpi was quite flaky on such old machines.
Comment 9 Christopher Brown 2007-10-01 05:03:52 EDT
You are right - ACPI implementation on old BIOS is flaky so the date check was
put in place in order that people understand that enabling ACPI could cause
problems. In your case it would seem that the BIOS update does not change the
date or the upgrade did not take place correctly.

In any case, I would be inclined to edit your grub.conf with acpi=force and
grubby should then update any later kernels with this option to save you having
to add this at each upgrade or every boot.

I'm also inclined to agree with Michael that this should be closed WONTFIX given
that it simply appears to be bad hardware or bad BIOS implementation.
Comment 10 nvwarr 2007-10-02 06:13:26 EDT
(In reply to comment #9)
> You are right - ACPI implementation on old BIOS is flaky so the date check was
> put in place in order that people understand that enabling ACPI could cause
> problems. In your case it would seem that the BIOS update does not change the
> date or the upgrade did not take place correctly.

When it boots, it definitely gives a date of 2002 (since the upgrade), whereas
before it really gave 1997. So I guess they probably forgot to change the string
in the update.

> In any case, I would be inclined to edit your grub.conf with acpi=force and
> grubby should then update any later kernels with this option to save you having
> to add this at each upgrade or every boot.

That is, in fact, what I did.

> I'm also inclined to agree with Michael that this should be closed WONTFIX given
> that it simply appears to be bad hardware or bad BIOS implementation.

Yes, I think that is reasonable. Forcing acpi sweeps the apm problem under the
carpet for me and I guess most people will have acpi by default, a lot of the
rest can force acpi, so there is probably a rather small fraction of computers
left, that can't do acpi, which will inevitably get smaller as old machines die.
Comment 11 Christopher Brown 2007-10-02 11:01:51 EDT
Okay, closing as such then. Thanks for the bug report.

Cheers
Chris

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