Red Hat Bugzilla – Bug 270321
tsc looses time and ntpd doesn't sync
Last modified: 2007-12-12 11:25:21 EST
Description of problem:
Kernel chooses tsc as clocksource but tsc loses ~3sec/min and ntpd never syncs.
Booting with clocksource=acpi_pm solves this problem. My hardware is a MSI P35
Neo2 motherboard and
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
stepping : 6
The scaling_governor is ondemand.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Boot with ntpd enabled
This kernel also has the double hpet in available_clocksource bug. Hope that
Um, there is no 2.6.23-rc4 kernel for Fedora 7. Did you mean to file against
No, I compiled my own kernel to check out the new scheduler. I don't know that
it is really a kernel specific problem as I don't know how the default
clocksource is chosen. The config is the f7 one except for the new parts. I
don't see anything in the config to select the default clocksource, but maybe I
am missing something?
(In reply to comment #2)
> No, I compiled my own kernel to check out the new scheduler.
It's already in the new Fedora 2.6.22 kernels.
> I don't know that
> it is really a kernel specific problem as I don't know how the default
> clocksource is chosen. The config is the f7 one except for the new parts. I
> don't see anything in the config to select the default clocksource, but
> maybe I am missing something?
Do the Fedora 2.6.22 kernels have the same problem? Can you try Fedora8 test2
when it's released?
Latest is here, it has CFS v20.5 plus a bugfix from the mailing list:
I gave the latest kernel a shot. As you can see from the ntpq output the tsc
drift is still bad.
remote refid st t when poll reach delay offset jitter
clock2.redhat.c .CDMA. 1 u 62 64 7 70.868 3635.60 2690.36
x1.tonyurban.co 18.104.22.168 3 u 59 64 7 52.314 3723.83 2754.86
all.ericspeaks. 22.214.171.124 3 u 62 64 7 86.755 3644.36 2667.77
This is after the first poll. On another note, I also see the boot message
usb 4-1: device descriptor read/all, error -71
But it may well just be hardware or the bios. I've noticed it with both fc6 and
f7 ever since I upgraded my machine.
Anything else I can do?
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.
I am CC'ing myself to this bug and will try and assist you in resolving it if I can.
There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?
If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.
Good news and bad news. Both 2.6.23-rc8 and 126.96.36.199-91.fc7 synced up on first
boot, but 2.6.23-rc8 failed on second boot. The tsc is still chosen as the time
source and still looks to be unreliable, the pm timer remains a better choice
for my machine. The hpet bug is fixed in rc8, so I will give that a try also.
This problem may be related to this posting on LKML:
Sorry to ping you for an update and then disappear for two months. Thanks for
the info anyway. Ingo indicated it has been applied so I'm closing as
NEXTRELEASE 2.6.24-rc1. Please re-open if its still an issue.