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.