From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.5) Gecko/20070718 Fedora/2.0.0.5-1.fc7 Firefox/2.0.0.5 Description of problem: When booting the latest kernel 2.6.22.5-76 on my ECS Elitegroup motherboard the clock runs at about 2X the normal speed. I have tried 'no_timer_check' and 'noapic' with no good results. I have updated the BIOS to the latest provided by the mfg. Version-Release number of selected component (if applicable): kernel-2.6.22.5-76/fc7 How reproducible: Always Steps to Reproduce: 1.boot kernel 2. do 'date' command several times to check time 3. Actual Results: time jumps between 2-7 seconds each time Expected Results: seconds should move normaly Additional info:
Created attachment 200971 [details] lspci -vv
Created attachment 200981 [details] cat /proc/interrupts
Created attachment 200991 [details] dmidecode
Please post /var/log/dmesg And try boot options: disable_timer_pin_1 or disable_8254_timer
Created attachment 201271 [details] Dmesg with disable_8254_timer When I did the disable_timer_pin_1 the system would not even boot
Comment on attachment 201271 [details] Dmesg with disable_8254_timer Time not fixed
last messages on the boot with 'disable_timer_pin_1' is: Loading keyring - Added public key 4A67DBB026B0246B - User ID: Red Hat, Inc. (Kernel Module GPG key) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) this is with kernel opts: disable_timer_pin_1 vga=ask boot_delay=30 earlyprintk=vga'
Please try: nohz=off highres=off and/or clocksource=acpi_pm
Created attachment 201441 [details] boot with nohz and highres off still no good clock still running fast
Created attachment 201461 [details] boot with clocksource - still fast clock
I am able to boot into kernel 2.6.18-1.2798.fc6 and not have the clock issue. I also can boot into the XEN kernel and the clock works fine.
even with older kernel 2.6.18-1.2798.fc6 I am getting syslog entries about Kernel sync time Sep 24 07:55:46 rio ntpd[2045]: kernel time sync error 0001 I will be trying to go back to Xen kernel but really don't want to run a Xen kernel
More things to try: apicmaintimer nohz=off highres=off noapictimer nohz=off highres=off
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. Have you been able to test the parameters above with the latest kernel?
I am also seeing this problem. I have an ECS (Elitegroup) GeForce 6100SM-M motherboard and an "AMD Athlon(tm) X2 Dual Core Processor BE-2300" (that's from /proc/cpuinfo). I discovered that the boot option "nosmp" will fix the problem. I have tried some other boot options from various web searches, but not all the ones listed above. I tried "clock=pit", "noapic", "nolapic", "no_timer_check". This is my uname -a: Linux juliet 2.6.23.1-10.fc7 #1 SMP Fri Oct 19 15:39:08 EDT 2007 i686 athlon i386 GNU/Linux I would really like to get this fixed as I am running with just half the CPU until it is. If there is anything I can do to help let me know.
There is now a common problems page with additional workarounds: https://fedoraproject.org/wiki/KernelCommonProblems
I tried "nohz=off highres=off", and then also "clocksource=acpi_pm", and these did not fix the problem. Perhaps that KernelCommonProblems page should be updated to indicate that those fixes don't work in all cases ?
Rob, What is the latest on this? I've seen a few posts with this issue and as you have said - various boot flags seem to work in some instances. Any progress? Have you tried: noapic acpi=off
I am running with kernel 2.6.23.1-10.fc7PAE with no special kernel arguments, and it works (i.e., clock runs at normal speed even with both processors working). I think I did something additional, such as a BIOS setting or something, but I cannot remember what it was. I took notes at the time but I don't have access to them. If I can get access there next week and figure out what it was, I will post here.
Okay, thanks for the feedback. I'm closing this CURRENT_RELEASE as per your comments but the original reporter can re-open if he needs to.