On 7 Dec 2002 at 15:14, Kurt Roeckx wrote:
> 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
>
>
> Kurt
>
On Mon, Dec 09, 2002 at 09:07:35AM +0100, Ulrich Windl wrote:
> 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