Bug 152170 - Clock runs approximately twice as fast as normal
Clock runs approximately twice as fast as normal
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
: 155112 159081 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-25 11:00 EST by Cynthia Jeness
Modified: 2015-01-04 17:18 EST (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-29 01:29:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch extracted from kerneltrap (970 bytes, patch)
2005-05-23 06:53 EDT, Toshio Kuratomi
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 3927 None None None Never

  None (edit)
Description Cynthia Jeness 2005-03-25 11:00:37 EST
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:
Comment 1 Pete Buechler 2005-04-23 22:45:26 EDT
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!
Comment 2 Pete Buechler 2005-04-23 23:31:35 EDT
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.
Comment 3 Cynthia Jeness 2005-04-25 12:46:49 EDT
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.
Comment 4 Pete Buechler 2005-04-29 00:29:12 EDT
I found that this problem has been reported on the kernel bugzilla: 
http://bugme.osdl.org/show_bug.cgi?id=4442
Comment 5 Frank Sander 2005-04-30 15:11:18 EDT
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.
Comment 6 Cynthia Jeness 2005-04-30 16:03:39 EDT
My motherboard is an MSI RS480M2 motherboard and see this problem.
Comment 7 dale 2005-05-02 01:32:58 EDT
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
Comment 8 Cynthia Jeness 2005-05-02 10:13:22 EDT
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.  
Comment 9 Tomas Mraz 2005-05-09 03:10:11 EDT
*** Bug 155112 has been marked as a duplicate of this bug. ***
Comment 10 Ken Nordquist 2005-05-09 11:36:30 EDT
[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. 
Comment 11 Toshio Kuratomi 2005-05-23 06:49:26 EDT
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.
Comment 12 Toshio Kuratomi 2005-05-23 06:53:01 EDT
Created attachment 114709 [details]
Patch extracted from kerneltrap

This is the kerneltrap patch applied against 2.6.11-1.1319.
Comment 13 Dave Miller 2005-05-30 19:45:20 EDT
Added myself to the cc: list since I'm seeing this on a HP Pavilion zv6015us
with the above mentioned chipset and CPU.
Comment 14 Toshio Kuratomi 2005-06-15 19:49:11 EDT
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. 
Comment 15 Cynthia Jeness 2005-06-16 11:29:41 EDT
Can you tell me exactly how you specify this boot option?
Comment 16 Toshio Kuratomi 2005-06-16 12:10:06 EDT
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.
Comment 17 Pete Buechler 2005-06-20 00:55:48 EDT
I tried booting with the no_timer_check option. It did not seem to make any
difference. Sigh.
Comment 18 Pete Buechler 2005-06-20 01:35:54 EDT
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.
Comment 19 Kyle R Maxwell 2005-06-20 09:58:27 EDT
*** Bug 159081 has been marked as a duplicate of this bug. ***
Comment 20 Dave Jones 2005-06-27 19:11:22 EDT
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.
Comment 21 Ken Nordquist 2005-06-27 20:26:17 EDT
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."
Comment 22 Dave Miller 2005-06-27 22:09:55 EDT
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
Comment 23 Kyle R Maxwell 2005-06-28 11:12:50 EDT
FC4-final (1369) definitely exhibits the same behavior, but no_timer_check fixes
it and I can use APIC again.
Comment 24 Ken Nordquist 2005-07-07 08:08:03 EDT
Just rebooted after installing the 2.6.12-1.1387_FC4 kernel and running with
no_timer_check with no problems.
Comment 25 Steven Pritchard 2005-07-12 10:40:15 EDT
The i686 kernel does not seem to have this issue on the MSI RS480M2-IL.
Comment 26 Steven Pritchard 2005-07-15 11:42:58 EDT
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.
Comment 27 Dave Jones 2005-09-30 02:42:36 EDT
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.
Comment 28 Ken Nordquist 2005-09-30 07:32:39 EDT
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.
Comment 29 Jorge Pereira 2005-10-11 14:08:37 EDT
I'm running  kernel 2.6.13-1.1526_FC4smp and i have the same problem!
Comment 30 Jorge Pereira 2005-10-12 05:40:16 EDT
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!
Comment 31 Frank Edwards 2005-10-17 14:11:20 EDT
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! 
 
 
Comment 32 Cynthia Jeness 2005-10-18 16:36:55 EDT
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.   
Comment 33 Ken Nordquist 2005-10-20 18:11:39 EDT
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!
Comment 34 David J. Rose 2005-10-28 03:48:59 EDT
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.
Comment 35 Mark 2005-11-09 11:24:40 EST
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.
Comment 36 Dave Jones 2005-11-10 14:46:50 EST
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.
Comment 38 Giuseppe Giannuzzi 2005-11-11 10:19:20 EST
Kernel 2.6.14-1.1637_FC4 doesn't fix the problem on my HP Pavilion zv6069ea.
Comment 39 Toshio Kuratomi 2005-11-12 12:14:42 EST
HP zv6000
2.6.14-prepkatahdin1.1637

Normal boot has problem.
Including no_timer_check as a boot option runs fine.
Comment 40 Ken Nordquist 2005-11-12 12:53:23 EST
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
Comment 41 Jeff Ridder 2005-11-29 23:04:49 EST
Problem continues to show up with 2.6.14-1.1644_FC4.
Comment 42 starlight 2005-12-05 21:17:30 EST
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.
Comment 43 Giuseppe Giannuzzi 2005-12-14 07:54:22 EST
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.
Comment 44 Dave Jones 2005-12-14 09:26:00 EST
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.
Comment 45 Giuseppe Giannuzzi 2005-12-14 09:40:36 EST
Of course I mean kernel-2.6.14-1.1653_FC4 ... just a slip! Sorry.
Thanks for your explanation.
Comment 46 Toshio Kuratomi 2006-01-20 21:08:52 EST
kernel-2.6.14-1.1656_FC4 works without boot options for me as well.
Comment 47 Henrik Nordstrom 2006-01-21 09:25:14 EST
2.6.15-1.1861_FC5.x86_64 exibits the same problem.

MSI RS480M2-IDL motherboard
Athlon 64 X2 4200+ CPU
Comment 48 Henrik Nordstrom 2006-01-21 09:32:13 EST
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.
Comment 49 Pete Buechler 2006-01-23 19:38:50 EST
Kernel 2.6.14-1.1656_FC4 works without the "no_timer_check" option for me as well.
Comment 50 Eric Sandeen 2006-01-30 23:50:44 EST
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.
Comment 51 Henrik Nordstrom 2006-02-02 20:52:46 EST
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?
Comment 52 Dave Jones 2006-02-03 00:43:05 EST
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.
Comment 53 Henrik Nordstrom 2006-02-03 07:42:48 EST
(Still) works for me on MSI RS482M4-IDL.
Comment 54 Giuseppe Giannuzzi 2006-02-03 09:06:52 EST
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.
Comment 55 Henrik Nordstrom 2006-02-03 10:52:58 EST
On a second inspection it is indeed broken again with this kernel. Appears I
accidently booted the 1656 kernel in my previous test..
Comment 56 Mark 2006-02-15 08:53:08 EST
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.
Comment 57 Henrik Nordstrom 2006-02-16 07:03:56 EST
According to the kernel bug report notsc should also work around the problem.
Haven't verified yet.
Comment 58 Henrik Nordstrom 2006-03-01 09:11:48 EST
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..
Comment 59 Henrik Nordstrom 2006-03-01 09:38:05 EST
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
Comment 60 Mark 2006-03-09 15:09:19 EST
Clock speed using kernel-2.6.15-1.1833_FC4 is too fast unless no_timer_check
option is used.
Comment 61 Patrick De Maziere 2006-04-10 08:50:35 EDT
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 ...
Comment 62 Henrik Nordstrom 2006-04-10 16:01:48 EDT
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.
Comment 63 Patrick De Maziere 2006-05-31 10:09:32 EDT
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 
   
Comment 64 Dave Jones 2006-07-29 01:29:13 EDT
The ATI chipset quirk should be fixed up in the current errata kernels.

Note You need to log in before you can comment on or make changes to this bug.