1.1.6 build fails on FC30

[ASSI]

Udo van den Heuvel via devel writes:
> When then is the jitter so low?
> If solely using NMEA the jitter and offset would be worse.

Well, run ntpq with the -u switch to see what those really are.  If
you've set the serial to low latency and a fairly high speed, you can
expect jitter in the single-to-double digit µs range, so it would show
up as all zero in ntpq in standard display mode.

> But: should ttyS0 show up in /proc/interrups? (ttyS1 does)

Don't know…

>> although from your boot log it's clear you were apparently expecting to
>> use that.  Have you set the flag to use the PPS and does the device
>> deliver (stable) PPS signal?  
>
> # ppswatch /dev/pps0
> trying PPS source "/dev/pps0"
> found PPS source "/dev/pps0"
> timestamp: 1586697390, sequence: 139, offset:  199075943
> timestamp: 1586698062, sequence: 140, offset:  196910388
> timestamp: 1586698062, sequence: 140, offset:  196910388
> timestamp: 1586698063, sequence: 141, offset:  196889843
> timestamp: 1586698063, sequence: 141, offset:  196889843
> timestamp: 1586698064, sequence: 142, offset:  196873213
> timestamp: 1586698064, sequence: 142, offset:  196873213
> timestamp: 1586698065, sequence: 143, offset:  196852628
> timestamp: 1586698065, sequence: 143, offset:  196852628
> timestamp: 1586698066, sequence: 144, offset:  196834846
> timestamp: 1586698066, sequence: 144, offset:  196834846
> timestamp: 1586698067, sequence: 145, offset:  196818850
> timestamp: 1586698067, sequence: 145, offset:  196818850
> timestamp: 1586698068, sequence: 146, offset:  196800678
> timestamp: 1586698068, sequence: 146, offset:  196800678
> timestamp: 1586698069, sequence: 147, offset:  196782262
> timestamp: 1586698069, sequence: 147, offset:  196782262
> timestamp: 1586698070, sequence: 148, offset:  196762613

That could become about 20µs jitter from eyeballing the data.  The
sequence numbers look awfully low though for a system that is up for a
while already?

> # ppswatch /chroot/ntpd/dev/pps0
> (shows similar output)

Good, but does ntpd see the same?

> Something is coming out of it.
>
>> If so, does the device file expected by
>> ntpd exist in your chroot environment (generally a symlink to the real
>> /dev/pps* device) and is it readable by ntpd?
>
> # ls -l /dev/*ps*
> lrwxrwxrwx 1 root root      5 Apr 12 11:58 /dev/gps0 -> ttyS0
> lrwxrwxrwx 1 root root      4 Apr 12 11:58 /dev/gpspps0 -> pps0
> crw-rw---- 1 root ntp  253, 0 Apr 12 11:58 /dev/pps0
> # ls -l /chroot/ntpd/dev/*ps*
> lrwxrwxrwx 1 root root      5 Mar  9  2018 /chroot/ntpd/dev/gps0 -> ttyS0
> lrwxrwxrwx 1 root root      4 Mar  9  2018 /chroot/ntpd/dev/gpspps0 -> pps0
> crw-r--r-- 1 ntp  ntp  253, 0 Nov  3 17:15 /chroot/ntpd/dev/pps0

The files used by ntpd should be gps0 / gpspps0.

>> Also, if there's an
>> apparmor profile for ntpd, check in /var/log/audit/audit.log (or
>> wherever that is under Fedora, also in the chroot maybe) that apparmor
>> allows the access as well.
>
> selinux is disabled.
> never used apparmor.

Fedora / RHEL traditionally wasn't using it, I have no idea what the
current state on these platforms is.  I just mentioned it because it can
cause an otherwise perfectly fine configuration to fail rather
obscurely.


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

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables