Description of problem: At a Asus P5A mainboard using a AMD K6-2 450 MHz processor, the kernels from Fedora Core 2 bring up the problem, that the system clock runs either too fast (more than twice times to fast using 2.6.5-1.358) and too slow (using 2.6.6-1.435.2.3). Version-Release number of selected component (if applicable): kernel-2.6.5-1.358.i586 kernel-2.6.6-1.435.2.3.i586 How reproducible & Steps to Reproduce: See above. Actual results: Well, the system clock is either too slow or too fast, but has no normal speed... Expected results: Working system clock with normal speed ;-) Additional info: Attaching you a lspci -vvv for further information.
Created attachment 101693 [details] Outpu from `lspci -vvv`
If you try a kernel from one of the following sources, does the problem still occur? + rawhide (a.k.a. FC-devel) + FC 3 test 1 + http://people.redhat.com/arjanv/2.6/
Sorry Barry, but the latest available Kernel 2.6 for Fedora Core didn't solve it: For the test, kernel-2.6.7-1.488.i586.rpm was used (that rpm is in Fedora Development and Arjan's public directory; they are synchron at current). The result, timed with a stopwatch: ~10 system seconds at the system are ~40 seconds realtime! :-(
I installed kernel 2.6.8 , same result
I'm running 2.6.8-1.521 with the result of a significantly slow clock. This is not an issue with a stock 2.6.8.1 kernel.
Excuse me, I was mistaken. I had an opprotunity to retest this today and it is occuring on a FC2 distribution with a 2.6.8.1 kernel from kernel.org using the same options as my custom FC2 kernel. This is occuring at the same ration as mentioned above: aprox 1:4
The system clock will keep correct time if my CPU is at 100% utilization. If I execute the following script to push my CPU to 100% and keep it there the system clock keeps time correctly while it is running. #!/bin/bash while [ 1 ]; do TEMP=0 done Not sure how to track this down with this clue however.
that's a useful observation; linux will call into the bios when idle (to let the bios do power saving) or will power save the cpu itself, at least by default. If you add "idle=poll" at the kernel commandline (use the "a" key in grub), does this get "fixed" too ?
Specifying idle=poll had no impact on kernel-2.6.8-1.521custom I am using ACPI support and cpufreqd with this kernel but performed my testing just now on AC power.
I'm seeing similar behavior on FC3 with an hp pavillion xt155 (1.2GHz Celeron) laptop. The clock is running much too slow, and can't keep the time without the assistance of ntp (which only helps so much). Kernel: 2.6.9-1.667
More information gleamed from a thread on fedoraforum.org: only the software clock is wrong; the hardware clock is correctly incrementing. Forumn thread: http://www.fedoraforum.org/forum/showthread.php?s=b0bdf81d479fa56d56c8553af0f0a5f4&t=19788
Same Problem on: processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping : 12 cpu MHz : 350.714 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow
Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you.
As per comment #10, I am seeing this on FC3. I cannot reopen the bug, nor change the version, due to being an unprivileged user.
Thank you Eric for posting this information; I've got no i586 computer any more at home - reopening and re-assigning.
586 era computers had very flaky ACPI support, we probably shouldn't even bother trying it and hoping it'll work (unless the user passes acpi=force). Does booting with acpi=off make this problem stop ? (They should have [hopefully working] APM support)
Running FC1 with a 2.4 kernel, no problems existed. Using FC3, my software clock runs 1 second for every 3 seconds realtime. This is on a P4-based Celeron laptop, with the following /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Mobile Intel(R) Celeron(R) CPU 1.80GHz stepping : 7 cpu MHz : 1794.704 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid bogomips : 3530.75 There is no APM support for this system; acpi is the only route to handle any power management at all. As far as I'm aware, this CPU is actually of the i686 class, not i586. For the mean time, I've been running a simple script to keep my software clock accurate: #!/bin/sh while true; do sleep 1; hwclock --hctosys; done which works because the hardware clock is accurate, only the system clock is lagging.
I am running Windoze XP on a Dell Insprion 8600 laptop so I can run FC3 under VMware. The hardware clock on under Windoze is just fine, as it was while running RH9 under VMware. The software clock on FC3 runs at about 1/6 the correct rate. In testing, I set the adjtimex adjustments to the max and this is the output of --compare: root@VMFC3 eb]# /sbin/adjtimex --compare=20 --interval 2 --- current --- -- suggested -- cmos time system-cmos 2nd diff tick freq tick freq 1114204694 -222.042326 -222.042326 11000 6553600 1114204704 -230.823175 -8.780849 11000 6553600 1114204715 -240.615795 -9.792620 11000 6553600 59964 643098 1114204726 -250.408407 -9.792612 11000 6553600 59964 385286 1114204737 -260.200979 -9.792573 11000 6553600 59964 -895960 1114204747 -268.993345 -8.792365 11000 6553600 54963 -1139712 1114204758 -278.785961 -9.792617 11000 6553600 59964 549348 1114204769 -288.578534 -9.792573 11000 6553600 59964 -895964 I run yum and apt-get update every few days, so the FC3 is as uptodate as I can make it. Any suggestions? -- Ewin
Is someone of you able to reproduce this problem with Fedora Core 4 test 1-3 or even with Rawhide?
I am also facing similar problem. I am having an old server with Linux 8 Kernel 2.4.18 and system clock is kind of stuck. I am running it on HP Netserver LT6000r machine. It goes backward and forward very repidly however BIOS time ( hwclock) is correct. What could have happened ? Any comments ? pratul
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
Dell Latitude D610 >> Fedora Core 4 >> Latest updates System and hardware clock run at about the same rate, which is about 5 seconds over 60 minutes faster than real time. The laptop constantly runs setiathome, so the CPU is constantly at 100%. Currently running ntpdate as a cron job to keep proper time.
Thank you, re-assigning for Fedora Core 4
I am having this problem as well, though the clock is running twice as fast as it should. 1 minute system time is 30 seconds real time. My Hardware however, is not an i586. I am running an Athlon64 on an MSI 7145 motherboard. I have read on some posts dealing with older kernel versions that simply recompiling the kernel to a newer version can fix this issue, but alas, that is not the case this time. I recieve this issue with the stock FC4 x86_64 Kernel from the install DVD (2.6.11-1.1369_FC4), and from the 2.6.12.5 kernel I compiled myself. Any information you might want about kernel configs or system configs I am willing to provide as I would like to try to get this issue resolved. Thanks.
Problem still present on FC4 kernel 2.6.12-1.1398_FC4smp. I have tried to build a custom kernel with HZ=100 in asm-i386/param.h (as suggested by the VMWare knowledge base), but that didn't solve anything.
Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks.
I had the same problem (system clock way too fast) with above kernel(2.6.13-1.1526_FC4) upgraded. AMD Athlon 64bit 3400+. regards! -ww
I Have the same problem (system clock way too fast) with above kernel(2.6.13-1.1526_FC4) upgraded. AMD AthlonM 64bit 3700+. see also Bug Nr. 170006 best regards sh
"Me too". 2.6.13-1.1526_FC4 AMD Athlon(tm) 64 Processor 3200+" System time seems to run about twice as fast as real time. i.e. "sleep 10" takes 5 seconds.
Additional information in case it matters. Motherboard: RS480M2-IL (part number MSI-7093) Upgrading the BIOS to the latest made no difference Someone else mentioned that they're using an MSI mobo as well.
Booting with kernel command line parameter no_timer_check=0 fixes the problem.
If your Motherboard as a built-in ATI XP chip then the bug is in fact due to the motherboard having two timer pins which gets handled wrong by the APIC portion of the kernel. This shouldn't be a problem with the new 2.6.14 kernel release, as the patch (see bug nr. 152170 ) to fix this issue appears to have been included in the kernel. I have not tested this kernel yet, but plan on doing so within the week. regards, djr
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
I just tested on the 1653 build and the clock appears to be working properly now.
Update: After running fine on an 1831 kernel for a while, the clock problem seems to have reoccurred. The clock is now running at double speed. The following kernel message was logged around the time that I noticed the clock going nuts: Losing some ticks... checking if CPU frequency changed.