adjtimex/ppskit
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Kurt Roeckx
I have this problem with the ntp/adjtimex. Ntpd sets the freq field to a value outside the valid range. According to Dave Mills, the kernel is supposed to clamp the frequency. I see that in the PPSkit this is done properly ...
Would it be possible to integrate the PPSkit in the kernel soon?
If not, could you atleast get parts of it in the kernel, so it works correctly with ntpd?
I see: The code used in v2.4.10 of the kernel reads like this:
if (txc->modes & ADJ_FREQUENCY) { /* p. 22 */
if (txc->freq > MAXFREQ || txc->freq < -MAXFREQ) {
result = -EINVAL;
goto leave;
}
time_freq = txc->freq - pps_freq;
}The PPSkit code reads like this:
if (txc->modes & MOD_FREQUENCY) { /* p. 22 */
long freq; /* frequency ns/s) */
freq = txc->freq / SCALE_PPM;
if (freq > MAXFREQ) {
result = -EINVAL;
freq = MAXFREQ;
} else if (freq < -MAXFREQ) {
result = -EINVAL;
freq = -MAXFREQ;
}
L_LINT(time_freq, freq);
#ifdef CONFIG_NTP_PPS
pps.freq = time_freq;#endif
(So just limit the argument in addition to returning -EINVAL; the other differences are because of the modified clock model and nanoseconds)
Returning "-EINVAL" is a subject to discussion, so it could be left out. I don't have the time to make a proper patch at the moment, but I think everyone could fix it until a proper patch is available.
Regards,
Ulrich
Quoted 4 lines
Kurt
Quoted 4 lines · Ulrich Windl
On 7 Dec 2002 at 15:14, Kurt Roeckx wrote:
the other
differences are because of the modified clock model and nanoseconds)
Is there a reason not to include the new clock model in the kernel?
I'll make a patch based on the ppskit if needed.
Kurt