1.1.6 build fails on FC30

[Udo van den Heuvel]

On 12-04-2020 14:55, ASSI via devel wrote:
> Udo van den Heuvel via devel writes:
>> Using tsc clocksource we get:
>>
>> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>> tsc
>> # ntpq -pn
>>      remote           refid      st t when poll reach   delay   offset
>>  jitter
>> ===============================================================================
>> +NMEA(0)         .GPS.            0 l    9   64  377   0.0000   0.0000   0.0019
>> *192.168.10.98   .GPS.            1 u   27   64  377   0.3096  -0.0919   0.1178
>> +fd00:c0a8:a00:1 .GPS.            1 u   37   64  377   0.3211  -0.0505   0.0775
>>
>> I.e.: no system peer selection of GPS.
>> We tried HPET, AC PI_PM and now TSC.
>> None of them works to fix this issue.
> 
> Then the clock isn't really the problem I suppose.  The GPS is reachable
> and has no offset and low jitter, but doesn't appear to use PPS;

When then is the jitter so low?
If solely using NMEA the jitter and offset would be worse.

But: should ttyS0 show up in /proc/interrups? (ttyS1 does)
Both are on a single pciE card.
Setserial shows:

# /bin/setserial /dev/ttyS0
/dev/ttyS0, UART: 16850, Port: 0xd0c0, IRQ: 37, Flags: low_latency
# /bin/setserial /dev/ttyS1
/dev/ttyS1, UART: 16850, Port: 0xd0c8, IRQ: 37

# cat /dev/gps0
(NMEA stream)

> 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

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

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

> 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.


Udo