Bug 270321 - tsc looses time and ntpd doesn't sync
tsc looses time and ntpd doesn't sync
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-31 02:09 EDT by charles harris
Modified: 2007-12-12 11:25 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-12 11:25:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description charles harris 2007-08-31 02:09:20 EDT
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):
kernel 2.6.23-rc4

How reproducible:
Always


Steps to Reproduce:
1.Boot with ntpd enabled
2.
3.
  
Actual results:


Expected results:


Additional info:

This kernel also has the double hpet in available_clocksource bug. Hope that
gets fixed.
Comment 1 Chuck Ebbert 2007-08-31 19:03:37 EDT
Um, there is no 2.6.23-rc4 kernel for Fedora 7. Did you mean to file against
rawhide?
Comment 2 charles harris 2007-08-31 19:14:48 EDT
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?
Comment 3 Chuck Ebbert 2007-08-31 20:19:55 EDT
(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:

http://koji.fedoraproject.org/koji/buildinfo?buildID=17344
Comment 4 charles harris 2007-08-31 21:40:35 EDT
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 128.105.37.11    3 u   59   64    7   52.314  3723.83 2754.86
 all.ericspeaks. 8.15.10.42       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?
Comment 5 Christopher Brown 2007-10-01 10:33:05 EDT
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.

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.
Comment 6 charles harris 2007-10-01 16:03:14 EDT
Hi Christopher,

Good news and bad news. Both 2.6.23-rc8 and 2.6.22.9-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.
Comment 7 charles harris 2007-10-19 14:18:43 EDT
This problem may be related to this posting on LKML:
http://marc.info/?l=linux-kernel&m=119254738106753&w=2
Comment 8 Christopher Brown 2007-12-12 11:25:21 EST
Hello Charles,

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.

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