ntpq change in behaviour

[Hal Murray]

ntpq gets pll offset via ntp_control using CS_K_OFFSET which gets it from 
ntx.offset

ntx comes from ntp_adjtime which is only updated if a big conditional which is 
all local and looks good.  But check for MODE6 errors in the log file.

There is nothing lockclock in that local area.

So my guess is that the normal path isn't putting the right stuff into the 
kernel.  We are missing a call to ntp_adjtime

-----------

What's going on here is that ntpq -c kernel is reading a bunch of stuff from 
the kernel.  Normally, it gets put there via ntpd but in the LOCKCLOCK case, 
it gets put there via whatever other program is disciplining the clock.

The background for that is the mode where a PLL in the kernel tracks a PPS.  
It's not available on most kernels so we don't talk about it much.  ntpd sets 
a bit which basically hands off timekeeping to the kernel - similar to 
LOCKCLOCK.

A likely candidate is a call to loop_config()

----

This looks fishy to me:
 * ENABLE_LOCKCLOCK: The LOOP_DRIFTINIT and LOOP_DRIFTCOMP cases are no-ops.

        case LOOP_DRIFTINIT:
#ifndef ENABLE_LOCKCLOCK
                if (clock_ctl.mode_ntpdate)
                        break;

        case LOOP_DRIFTINIT:
               if (!lockclock || clock_ctl.mode_ntpdate)
                        break;

I just pushed a fix - removing the !.
Untested so far.  I'm about to start serious testing.


-- 
These are my opinions.  I hate spam.