Bug 2160

Summary: xntp3 does not actually set PLL update mode
Product: [Retired] Red Hat Linux Reporter: Chris Siebenmann <cks-rhbugzilla>
Component: xntp3Assignee: Jeff Johnson <jbj>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5.2   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-04-13 19:35:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Chris Siebenmann 1999-04-13 06:24:05 UTC 
The 5.2 xntp3 RPM, despite being happy to set the kernel
clock and track time and stuff, does not actually appear
to use the kernel-level PLL facilities. For example,
adjtimex --print will report 'status: 64' (clock
unsynchronized).

 Among other problems, this will cause the kernel not
to update the hardware CMOS clock every so often. This
will in turn cause a machine to potentially jump a lot
of time when rebooted.

 The best cure for this appears obscure to me,
unfortunately. I have become lost in a twisty
maze of source RPMs and autoconf.
Comment 1 Jeff Johnson 1999-04-13 19:35:59 UTC 
Running Red Hat 6.0 with a 2.2 kernel, adtimex --print reports
status: 1 (PLL updates enabled), so the PLL code appears functional
in 2.2 kernels.

Setting the CMOS clock can be done within xntp, but is not an
essential part of xntpd functionality. Since xntp3 syncs to reference
clocks quite well even without the PLL code, you can set your
CMOS clock manually with other utilities whenever xntpd shows
an acceptably small offset to a reference clock.