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.
Confirmed. My system clock started losing a few seconds every minute since I boot with acpi=off.
> 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.
(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.
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
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.
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) [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.
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. Cheers Chris