1.1.6 build fails on FC30

[Achim Gratz]

Udo van den Heuvel via devel writes:
> I do not understand why NO_HZ is necessary or even usable without
> conflict witgh PPS such as CONFIG_NO_HZ_COMMON.

NO_HZ has been the default configuration for a long time and it doesn't
have anything to do with the PPS API support.  The _only_ conflict is
with NTP_PPS, which predates NO_HZ and never has been adapted for it.

>> Once you have that working correctly you can try to enable hardpps, 
>
> How?

By switching off NO_HZ configuration (assuming you don't care about the
other side effects that's going to have) and switching on NTP_PPS.  You
can then compare that with the performance of the previous kernel config
and decide if its worth the trouble.  My experience is that even without
hardpps the clock can be controlled to much better precision than can be
transferred even over LAN.

> Yes, that makes the /dev/pps0 device appear.

It also sends the PPS events to the kernel in your current
configuration, which should recognizably change the clock rate.

> We start ntpd after this step.

…configured with or without flag3 set?

> Sure, in the chroot (!) the devices (created with mknod) are owned by ntp:

Then run the ppstest in the chroot also, perhaps?  Anyway, I'd think
the device should still be owned by root, but group ntp.  If Fedora uses
apparmor, you also need to add the device to the apparmor profile or
ntpd will not be able to open it (check the audit log for errors).

> If I run ntpd outside of the chroot the error does not appear and PPS
> works.

With or without the time going backwards?

> So we take another look at the chroot...

I'm not sure the chroot really buys you anything, security-wise.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra