Red Hat Bugzilla – Bug 211902
Time runnig at double speed on 2.6.18-1.2200.fc5/2.6.18-1.2798.fc6 (i586)
Last modified: 2007-12-31 02:05:31 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20060913 Fedora/220.127.116.11-1.fc5 Firefox/18.104.22.168 pango-text
Description of problem:
Time is advancing at double speed on my K6 III/450 ASUS P5A based machine when running the latest kernel.
All is OK with the previous kernel.
In the dmesg output both kernels show similar values for processor speed
2187 451.098 mhz 903.21 bogo mips and lpj 1806438
2200 451.068 mhz 902.78 bogo mips and lpj 1805564
So a timing loop error exists somwhere in the 2200 i586 kernel to cause the clck to run at double speed.
i initially spotted this thinking my ADSL had gone slow as a speed test which usually takes 27 seconds and returns a speed of 960k was returning a speed of 480k and showing as taking 54 seconds but speed tests on another machine gave the expected valus so I timed the test and found it to be reporting taking twice as long as it actually was ant therefore showing half the speed. I then booted into the previous kernel and found all was well again.
I will attach complete dmesg output from both kernels.
Version-Release number of selected component (if applicable):
kernel 2.6.18-1.2200.fc5 i586
Steps to Reproduce:
boot into 2200
Not to be in a time warp
Created attachment 139158 [details]
Created attachment 139159 [details]
Created attachment 139649 [details]
I originally filed this bug against the latest kernel for FC5 but just having
installed FC6 the default kernel has the same problem on my ASUS P5A so I will
be reverting it back to FC5 after this bug update.
Modifying bug to FC6 but it may be more appropriate to leave it as FC5 or even
show it as DEVEL as this is where the frantic kernel updates will get done once
FC7 development starts in ernist.
IF it would help I could run this system in rawhide mode or just boot into any
test kernel for FC5 to help diagnose the problem.
Updated to show FC6 Kernel in summary
does it go normal again if you boot with clocksource=tsc ?
Looks to be due to the removal of verify_pmtmr_rate(). If I recall, it was
pulled as it slowed down boot times and there was some question as if it was
actually necessary (x86_64 didn't need it).
The question now regarding a fix is:
1) Do we just blacklist the affected chipset, using the current acpi_pm
blacklist infrastructure? Or...
2) Re-add the verify_pmtmr_rate dynamic detection code.
I can confirm that if you boot with clocksource=tsc all is now well using the
latest FC5 kernel (2.6.18-1.2239.fc5) on my ASUS P5A box.
I presume the same fix should work for FC6 but I will wait for confirmation
before going through a backup of all data and installing FC6.
Presumably I could add this parameter during instalation so I may be able to
test if the fix works for FC6 without having to re-install if there is some way
of checking the time (from a console perhaps) before you commit yourself to do
David, could you please attach dmidecode output?
A fix for this (re-adding the verify_pmtmr_rate code) has been sent to Andrew.
I have tried the above recommendations and this didn't correct the time on my
computer. Please advise how I should proceed.
I have added clocksource=tsc to the /etc/grub.conf file and the clock is now
running at normal speed. I have 2.6.19-1.2895.fc6 for my kernel
clocksource=tsc worked for me too. I was really wondering what was going on
when my server started running at double time...
Re comment #9
Sorry I missed the request for further info my ISP's spam filter has
occasionally been eating e-mails that should get forwarded to my test-list folder.
Anyway I am attaching it now.
Created attachment 147696 [details]
Info as requested sorry for the delay hope it helps
System is now running FC6 and since instalation has had the suggested fix (i.e
clocksource=tsc) added to the grub file.
System is currentl upto date running the latest kernel and I havent tried it
without the fix.
Per comment #15, I'm not sure whether you think that this bug can be closed or not.
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, however this version of Fedora is no longer
Please attempt to reproduce this bug with a current version of Fedora (presently
Fedora 8). If the bug no longer exists, please close the bug or I'll do so in a
few days if there is no further information lodged.
Thanks for using Fedora!
I'm running F8 now and I don't need that kernel parameter. It's working fine now.
In that case, I'll close this one CURRENTRELEASE. Thanks!