Red Hat Bugzilla – Bug 244177
Reading /proc/apm slows down system clock
Last modified: 2007-11-30 17:12:07 EST
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
Version-Release number of selected component (if applicable):
and probably others...
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.
reading /proc/apm frequently slows down the system clock
clock should run normally.
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.
Perhaps this should be considered a security issue, because it allows a
non-privileged user to slow down the system clock.
My system clock started losing a few seconds every minute
since I boot with acpi=off.
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
(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
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."
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.
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.
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.
Sorry to take so long to get back to you.
The problem persists with the 220.127.116.11-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.
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?
Created attachment 212051 [details]
Output from dmidecode
(In reply to comment #7)
> Created an attachment (id=212051) 
> 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.
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.
(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.
Okay, closing as such then. Thanks for the bug report.