Bug 2160 - xntp3 does not actually set PLL update mode
xntp3 does not actually set PLL update mode
Product: Red Hat Linux
Classification: Retired
Component: xntp3 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Depends On:
  Show dependency treegraph
Reported: 1999-04-13 02:24 EDT by Chris Siebenmann
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1999-04-13 15:35:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chris Siebenmann 1999-04-13 02:24:05 EDT
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

 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 15:35:59 EDT
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.

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