Bug 2160 - xntp3 does not actually set PLL update mode
Summary: xntp3 does not actually set PLL update mode
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xntp3
Version: 5.2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-04-13 06:24 UTC by Chris Siebenmann
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-04-13 19:35:49 UTC

Attachments (Terms of Use)

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

 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.

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