From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041109 Firefox/1.0 Description of problem: The incremental seconds reported by "hwclock --show" seem to be running twice as fast as expected. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.hwclock --show 2.Check the time and wait a known interval 3.hwclcok --show 4.compare the time difference to the actual time difference as reported by a wall clock. Actual Results: Interval reported by successive hwclock commands is twice as long as expected, Expected Results: hwclock should match wall clock. Additional info:
Hi, this is Pete Buechler. I got the same problem. I have an emachines t6212, with an Athlon64 processor. I can work around it by disabling the ACPI in my BIOS and then when I come up all is well with the system clock. But, suddenly, my network starts going real slow. If I turn on the ACPI again, the network works, but my sytem time goes nuts. Argh!
I meant to say APIC, as in the interrupts, not ACPI, as in power management. When I disable APIC the system time runs well but the network stinks. This is on FC3, for me.
I see the same result as Pete if I disable APIC on boot by specifying "noapic" to Grub. The clock works perfectly, but the network is awful. Is this deemed to be a kernel problem, an APIC problem or a problem with the bios on the mother board. My motherboard is ASUS MSI RS48042. Since not all AMD64 users see this problem, I assume that the problem only occurs in connection with certain motherboards.
I found that this problem has been reported on the kernel bugzilla: http://bugme.osdl.org/show_bug.cgi?id=4442
The bug also is reportet in: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155112 were it seems to be related to the ATI RAdeon Xpress rs200 I have the same trouble and have an ATI based motherboard (don't know the exact chipset) I guess there might be a relation.
My motherboard is an MSI RS480M2 motherboard and see this problem.
same problem, except workaround will not suffice if I turn off APIC, then my eth0 does not make it through the boot process, it says that the pings timed out, or were to long from my router
The workaround is not viable for another reason. I updated my motherboard bios hoping that this would help. Now, if I turn off APIC, the boot process hangs. Previously the computer would boot OK but the network performance was atrocious. So I think that APIC needs to be fixed.
*** Bug 155112 has been marked as a duplicate of this bug. ***
[repost from bug 155112] System clock runs at 2x faster than it should. From extensive Google searches, it appears this is a problem w/ATI RS200 chipset and the kernel. An excellent thread outlining the problem can be found here: http://kerneltrap.org/mailarchive/1/search/subject/clock%20runs%20at%20double%20speed%20on%20x86_64%20system%20w/ATI%20RS200%20chipset and confirmation of the problem can be found here: http://scottstuff.net/scott/archives/000391.html For my comparison purposes, I sync'd the hardware clock with the system clock by 'ntpdate pool.ntp.org && hwclock -w', waited approximately fifteen minutes and ran 'hwclock --show' and compared it to the system clock. The result is the system clock was fifteen minutes ahead of the hardware clock. The motherboard I use is the MSI RS480M2-IL.
I can confirm that the timerhack patch in the kerneltrap thread fixes the clock skew for me. I'm using an HP laptop with the mentioned ATI XPress 200 chipset.
Created attachment 114709 [details] Patch extracted from kerneltrap This is the kerneltrap patch applied against 2.6.11-1.1319.
Added myself to the cc: list since I'm seeing this on a HP Pavilion zv6015us with the above mentioned chipset and CPU.
FC4 final kernel (kernel-2.6.11-1.1369_FC4) has an option no_timer_check). Looking at the source, it appears to do the same thing that timerhack did. I am able to use this as a boot option and it works just as the timerhack patch.
Can you tell me exactly how you specify this boot option?
In /boot/grub/grub.conf. There should be a section like this: title Fedora Core (2.6.11-1.1369_FC4) root(hd0,0) kernel /boot/vmlinuz-2.6.11-1.1369_FC4 ro root=/dev/hda1 no_timer_check initrd /boot/initrd-2.6.11-1.1369_FC4.img As you can see, I added no_timer_check to the end of the "kernel" line. On reboot, the grub menu will display the list of kernels to boot into. By selecting this one from the list you should boot with the no_timer_check feature enabled.
I tried booting with the no_timer_check option. It did not seem to make any difference. Sigh.
I should have mentioned, however, that I still use FC3. I grepped through the code for 2.6.11-1.27_FC3 and did not find a no_timer_check option, so it's not a big surprise that it did not do anything.
*** Bug 159081 has been marked as a duplicate of this bug. ***
Mass update of -test bugs to update version to fc4. (Please retest on final release, and report results if you have not already done so). Thanks.
I have kernel-2.6.11-1.1369_FC4 installed and running it with the no_timer_check option. The clock runs OK, loses about five seconds per week or so. Is the patch a stop-gap measure or has the patch been finalized upstream? I ask that because I wonder if the ATI people had a reason for having double the clock cycles as "normal."
Still seeing this with FC4 final kernel on a HP Pavilion laptop (zv6015us). Only by setting no_timer check at boot do I come close to keeping accurate time. Stock FC4 x86_64 kernel: uname -r 2.6.11-1.1369_FC4
FC4-final (1369) definitely exhibits the same behavior, but no_timer_check fixes it and I can use APIC again.
Just rebooted after installing the 2.6.12-1.1387_FC4 kernel and running with no_timer_check with no problems.
The i686 kernel does not seem to have this issue on the MSI RS480M2-IL.
Make that the i686 UP kernel does not have this issue, presumably because it doesn't use the IO-APIC. The i686 xen0 kernel doesn't even boot (bug #163370), even with the noapic option.
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 just upgraded to the 2.6.13-1.1526_FC4 kernel and the clock still ran approximately 2x faster without running the no_timer_check option. The clock does not skew when using the no_timer_check option.
I'm running kernel 2.6.13-1.1526_FC4smp and i have the same problem!
After reading this thread i tryed to run my 2.6.13-1.1526_FC4 kernel with no_timer_check and the problem persisted. My mother board is an ASUS A8N-E with a AMD 64 X2. Some software like Xine plays smothly now but the clock continuous to run must faster!
I apologize for adding a SUSE solution to a Fedora bug tracking list. But I have solved all of the performance/useability issues with my emachines T6212 (see Comment #1) which uses the MSI motherboard and ATI XPRESS 200 integrated video. I'm running SUSE Linux 10.0 (not the beta) with the stock 2.6.13-15-default kernel for the x86_64 platform that is provided by SUSE. I add the following to the boot line: acpi=noirq irqfixup nolapic pci=biosirq I now have no clock problems, no network delays (ping ~0.25ms average on 100Mb LAN), and the USB appears to work (only tested with the MemoryStick reader). The kernel gurus can figure why I need those options to make things work. :) (In reply to comment #30) > After reading this thread i tryed to run my 2.6.13-1.1526_FC4 kernel with > no_timer_check and the problem persisted. My mother board is an ASUS A8N-E with > a AMD 64 X2. Some software like Xine plays smothly now but the clock continuous > to run must faster!
I will add an alternative solution which I found on the Suse news groups: noapic pci=noacpi pci=routeirq As soon as I added these boot options back in June, then my clock began to work correctly, my network works with good performance and my USB seems to work. I would certainly like to know what all of these things mean and what is really going on with the clock. Further what is the effect of these options versus those presented in the prior post. My motherboard is an MSI RS480M2.
I had problems using 'noapic pci=noacpi pci=routeirq' individually because of SATA issues, but my clock problems stopped when using all three of these kernel options together. I too have an MSI RS480M2 mobo (desktop). Thanks Cynthia!
If you are using an ATI XP motherboard (atiixp) then the problem is due to the fact that your motherboard (same as mine) has a doube timer pin that the kernels apic code does not know how to handle. When experimenting with Suse linux I noticed that I did not have that problem. So, after searching theu there custom patched kernel sources, and doing diffs against the mainstream kernel source (2.6.13.1) I found that Suse has added a function in the apic code to disable one of the timer pins, fixing the problem. I am currently trying to find out from suse if this code is proprietary or not (have tried emailing them, and have recently posted in their forum (http://www.suseforums.net/index.php?s=77fa244e2dca7ea47be4683dfa95cdcc&showtopic=17106)). I have the needed patches to add this code to the 2.6.13.1 source on my machine now, but since I do not know if it is protected code, I do not know if I can post it here, or file it with the kernel ppl. at kernel.org. If anybody nows somebody that works for novell/suse then perhaps we can get this problem resolved faster.
After installing the 2.6.13-1.1526 kernel on my eMachines T6212 (see comment 1) the reboot problem was corrected. When I also added the no_timer_check (see comment 16) boot option the clock speed problem appears to be also corrected.
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.
Kernel 2.6.14-1.1637_FC4 doesn't fix the problem on my HP Pavilion zv6069ea.
HP zv6000 2.6.14-prepkatahdin1.1637 Normal boot has problem. Including no_timer_check as a boot option runs fine.
Clock is fast on normal boot w/2.6.14-1.1637_FC4 kernel. Works fine with kernel options: 'noapic pci=noacpi pci=routeirq' Mobo: MSI RS480M2-IL
Problem continues to show up with 2.6.14-1.1644_FC4.
Same problem on new Compaq Presario SR1030Z. 'noapic' fixes clock but integrate Ethernet stops working. 'noapic pci=noacpi pci=routeirq' doesn't help restore Ethernet. 'no_timer_check' also fixes clock but kills Ethernet. RHEL 4 doesn't seem to have 'no_timer_check' (tried FC4 kernel in desperation), so I've settled on using 'noapic' and stuffing a NIC card in the machine to work around the dead integrated NIC. RHEL 4 bug 153155.
kernel-2.6.14-1.1644_FC4 has a workaround for this bug. I updated the kernel and the clock runs normally. I am curious to know how this workaround works and if it must be considered as the final patch. Thanks.
you mean 1653 I assume ? (Commet #41 shows 1644 still broken). 1653 has two fixes First, we use the pm timer by default now over TSC, as its more accurate. Second, there's a quirk for certain ATI chipsets that we workaround. I'll leave this open for a day or two in case its still broken for anyone else on this bug.
Of course I mean kernel-2.6.14-1.1653_FC4 ... just a slip! Sorry. Thanks for your explanation.
kernel-2.6.14-1.1656_FC4 works without boot options for me as well.
2.6.15-1.1861_FC5.x86_64 exibits the same problem. MSI RS480M2-IDL motherboard Athlon 64 X2 4200+ CPU
no_timer_check fixes the problem. Correction: It's a MSI RS482M4-ILD motherboard. And as many others in this thread it is based on the ATI Radeon XPress 200 chipset.
Kernel 2.6.14-1.1656_FC4 works without the "no_timer_check" option for me as well.
Andi's patches listed towards the end of the linked kernel.org 3927 bugzilla entry (apic-main-timer + apic-main-timer-ati) fixed the problem for me with the latest 2.6.16-rc1-git4 kernel... so they would probably apply equally well to the FC5 test kernels.
Andi's patches did not work for me on 2.6.15-1.1884_FC5.x86_64 (2.6.16-rc1-git4 based), still had to specify the "no_timer_check" option. Also complains about NMI watchdog being stuck. However I can confirm that FC4 with "2.6.14-1.1656_FC4smp" does work fine with no special boot options, and also no complaints about the NMI watchdog here. Should I perhaps open a new report about FC5 on this?
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
(Still) works for me on MSI RS482M4-IDL.
After kernel update to 2.6.15-1.1830_FC4, the bug is come back ... previous kernel-2.6.14-1.1656_FC4 works fine.
On a second inspection it is indeed broken again with this kernel. Appears I accidently booted the 1656 kernel in my previous test..
The 2.6.15-1.1831_FC4 kernel continues to run twice as fast on the MSI RS480M2 motherboard, but using the no_timer_check reduces it to normal speed.
According to the kernel bug report notsc should also work around the problem. Haven't verified yet.
kernel-2.6.15-1.1977_FC5.x86_64 (2.6.16-rc4-git6) works fine for me with no extra boot parameters. upstream bugreport indicates the problem should be solved in 2.6.16-rc5, but I guess the changes is included in rc4-git6 as well..
Sorry, confused by rpm --changelog (gave me the wrong kernel...). Correct kernel which works is 2.6.15-1.1996_FC5 (2.6.16rc5-git3) and naturally includes the timer changes mentioned in the upstream bug report. The earlier kernel-2.6.15-1.1977_FC5 does not work even if I just said so.. Suggestion to kernel package maintainer: Change numbering scheme used to more accurately reflect the upstream version used when using -rcX releases. Today it's quite confusing to track Fedora development kenel versions compared to upstream.. I would suggest a numbering scheme like the following 2.6.16-0.rc5git3.1977_FC5
Clock speed using kernel-2.6.15-1.1833_FC4 is too fast unless no_timer_check option is used.
Well, I can tell you that's not only Radeon/ATI related: Got this: MSI K8N Neo4 Platinum / Socket 939 / nVidia nForce 4 Ultra / ATX motherboard, with an Asus Extreme N6200GE TD nVidia GeForce 6200 128MB TV/Out DVI-to-2nd VGA adaptor PCI-Express; AMD Athlon 64 X2 4400+ (2.2 Ghz) - Dual Core - Boxed with Cooler. Running FC3, 2.6.12-1.1381_FC3smp. Clock is a mess, but seems to be interupt-steered: changing windows or pressing keys does increase the problem ... Maybe, it's MSI related ...
The "clock runs at double speed" is defenitely ATI related. nVidia has it's own clock issues however. Completely unrelated to the ATI chipset issues.
Could be, but I got problems as well... Albeit that I got the problem solved since a week for my machine (see above): BIOS settings: HT witdh: 8 up 8 down PCIE spread: no Clock spread: no CPU spread no and as boot option clock=pmtmr if you run vmwares: make them use one processor, not two btw, you can find more /related info in a good document of vmware: Timekeeping in VMwar Virtual Machines enjoy
The ATI chipset quirk should be fixed up in the current errata kernels.