| 2020-05-05 10:18:10 |
Christian Ehrhardt |
description |
I am working with gpsd and a pulse-per-second (PPS) signal on a serial port.
GPSD is able to detect the PPS signal but it is not able to use Kernel PPS for lower jitter. Here are the relevant log lines when PPS is being detected and enabled:
gpsd:INFO: KPPS:/dev/ttyS0 device not found.
gpsd:WARN: KPPS:/dev/ttyS0 kernel PPS unavailable, PPS accuracy will suffer
gpsd:PROG: PPS:/dev/ttyS0 thread launched
gpsd:INFO: PPS:/dev/ttyS0 ntpshm_link_activate: 1
gpsd:PROG: TPPS:/dev/ttyS0 ioctl(TIOCMIWAIT) succeeded, time: 1586594708.000179259, state: 0
gpsd:PROG: TPPS:/dev/ttyS0 Clear, cycle: 1586594708000179, duration: 1586594708000179 @ 1586594708.000179259
gpsd:PROG: PPS:/dev/ttyS0 Clear cycle: 1586594708000179, duration: 1586594708000179 @ 1586594708.000179259
gpsd:PROG: TPPS:/dev/ttyS0 ioctl(TIOCMIWAIT) succeeded, time: 1586594708.100154827, state: 64
gpsd:PROG: TPPS:/dev/ttyS0 Assert, cycle: 1586594708100154, duration: 99975 @ 1586594708.100154827
gpsd:PROG: PPS:/dev/ttyS0 Assert cycle: 1586594708100154, duration: 99975 @ 1586594708.100154827
gpsd:PROG: PPS:/dev/ttyS0 Assert ignored missing last_fixtime
gpsd:PROG: TPPS:/dev/ttyS0 ioctl(TIOCMIWAIT) succeeded, time: 1586594709.000117775, state: 0
gpsd:PROG: TPPS:/dev/ttyS0 Clear, cycle: 999938, duration: 899962 @ 1586594709.000117775
gpsd:PROG: PPS:/dev/ttyS0 Clear cycle: 999938, duration: 899962 @ 1586594709.000117775
gpsd:INFO: PPS:/dev/ttyS0 Clear hooks called clock: 1586594709.000117775 real: 1586594709.000000000: no fix
gpsd:PROG: PPS:/dev/ttyS0 Clear no fix @ 1586594709.000117775 offset -0.000117775
gpsd:PROG: TPPS:/dev/ttyS0 ioctl(TIOCMIWAIT) succeeded, time: 1586594709.100167645, state: 64
gpsd:PROG: TPPS:/dev/ttyS0 Assert, cycle: 1000012, duration: 100049 @ 1586594709.100167645
gpsd:PROG: PPS:/dev/ttyS0 Assert cycle: 1000012, duration: 100049 @ 1586594709.100167645
gpsd:PROG: PPS:/dev/ttyS0 Assert ignored this second already handled
The kernel does have PPS configured and the pps_ldisc module loaded. I think GPSd actually drove the loading of the module but I am not sure. I see the module being loaded and the serial port becoming a pps0 source during the boot sequence:
10:34:09 doorway kernel: [ 8.691161] pps_ldisc: PPS line discipline registered
10:34:09 doorway kernel: [ 8.691686] pps pps0: new PPS source serial0
10:34:09 doorway kernel: [ 8.691714] pps pps0: source "/dev/ttyS0" added
This is confirmed with ppsfind:
$ ppsfind ttyS0
pps0: name=serial0 path=/dev/ttyS0
And this pps0 device is working well:
$ sudo ppswatch /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
timestamp: 1586596125, sequence: 1418, offset: 85067
timestamp: 1586596125, sequence: 1418, offset: 85067
timestamp: 1586596126, sequence: 1419, offset: 81949
timestamp: 1586596126, sequence: 1419, offset: 81949
timestamp: 1586596127, sequence: 1420, offset: 80119
timestamp: 1586596127, sequence: 1420, offset: 80119
timestamp: 1586596128, sequence: 1421, offset: 81099
timestamp: 1586596128, sequence: 1421, offset: 81099
So, the kernel PPS subsystem is there and appears to be perfectly happy with the pps0 coming from /dev/ttyS0 but still GPSD appears unable to use all of that. |
[Impact]
* Current GPSD apparmor isolation is too strict to use PPS devices
properly.
* backport changes we added to 20.10 to fix this
[Test Case]
* Set up a PPS device with chrony/gpsd as described in [1]
Check the log output.
Bad case:
gpsd:INFO: KPPS:/dev/ttyS0 device not found.
gpsd:WARN: KPPS:/dev/ttyS0 kernel PPS unavailable, PPS accuracy will suffer
Good case does not show the errors above. Check that gpsd properly
initializes the device by ensuring this works for the whole stack
and chrony ends up getting proper PPS time data (also in [1]).
[1]: https://ubuntu.com/server/docs/network-ntp
[Regression Potential]
* As always with apparmor changes the regression risk comes in two way:
- we allow more than before, that could be insecure but we have the +1
from the security team and optimized to further reduce permissions.
- we deny some access (to silence warnings) which could, if strictly
required for un-tested use cases break these use-cases. Neither in the
tests nor in the review/discussion such cases were identified.
[Other Info]
* This is accepted in Debians packaging git, if not in Groovy in time I'll
need to put an 3.20-8ubuntu1 there, but I can preparing the SRU
independent to that.
----
I am working with gpsd and a pulse-per-second (PPS) signal on a serial port.
GPSD is able to detect the PPS signal but it is not able to use Kernel PPS for lower jitter. Here are the relevant log lines when PPS is being detected and enabled:
gpsd:INFO: KPPS:/dev/ttyS0 device not found.
gpsd:WARN: KPPS:/dev/ttyS0 kernel PPS unavailable, PPS accuracy will suffer
gpsd:PROG: PPS:/dev/ttyS0 thread launched
gpsd:INFO: PPS:/dev/ttyS0 ntpshm_link_activate: 1
gpsd:PROG: TPPS:/dev/ttyS0 ioctl(TIOCMIWAIT) succeeded, time: 1586594708.000179259, state: 0
gpsd:PROG: TPPS:/dev/ttyS0 Clear, cycle: 1586594708000179, duration: 1586594708000179 @ 1586594708.000179259
gpsd:PROG: PPS:/dev/ttyS0 Clear cycle: 1586594708000179, duration: 1586594708000179 @ 1586594708.000179259
gpsd:PROG: TPPS:/dev/ttyS0 ioctl(TIOCMIWAIT) succeeded, time: 1586594708.100154827, state: 64
gpsd:PROG: TPPS:/dev/ttyS0 Assert, cycle: 1586594708100154, duration: 99975 @ 1586594708.100154827
gpsd:PROG: PPS:/dev/ttyS0 Assert cycle: 1586594708100154, duration: 99975 @ 1586594708.100154827
gpsd:PROG: PPS:/dev/ttyS0 Assert ignored missing last_fixtime
gpsd:PROG: TPPS:/dev/ttyS0 ioctl(TIOCMIWAIT) succeeded, time: 1586594709.000117775, state: 0
gpsd:PROG: TPPS:/dev/ttyS0 Clear, cycle: 999938, duration: 899962 @ 1586594709.000117775
gpsd:PROG: PPS:/dev/ttyS0 Clear cycle: 999938, duration: 899962 @ 1586594709.000117775
gpsd:INFO: PPS:/dev/ttyS0 Clear hooks called clock: 1586594709.000117775 real: 1586594709.000000000: no fix
gpsd:PROG: PPS:/dev/ttyS0 Clear no fix @ 1586594709.000117775 offset -0.000117775
gpsd:PROG: TPPS:/dev/ttyS0 ioctl(TIOCMIWAIT) succeeded, time: 1586594709.100167645, state: 64
gpsd:PROG: TPPS:/dev/ttyS0 Assert, cycle: 1000012, duration: 100049 @ 1586594709.100167645
gpsd:PROG: PPS:/dev/ttyS0 Assert cycle: 1000012, duration: 100049 @ 1586594709.100167645
gpsd:PROG: PPS:/dev/ttyS0 Assert ignored this second already handled
The kernel does have PPS configured and the pps_ldisc module loaded. I think GPSd actually drove the loading of the module but I am not sure. I see the module being loaded and the serial port becoming a pps0 source during the boot sequence:
10:34:09 doorway kernel: [ 8.691161] pps_ldisc: PPS line discipline registered
10:34:09 doorway kernel: [ 8.691686] pps pps0: new PPS source serial0
10:34:09 doorway kernel: [ 8.691714] pps pps0: source "/dev/ttyS0" added
This is confirmed with ppsfind:
$ ppsfind ttyS0
pps0: name=serial0 path=/dev/ttyS0
And this pps0 device is working well:
$ sudo ppswatch /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
timestamp: 1586596125, sequence: 1418, offset: 85067
timestamp: 1586596125, sequence: 1418, offset: 85067
timestamp: 1586596126, sequence: 1419, offset: 81949
timestamp: 1586596126, sequence: 1419, offset: 81949
timestamp: 1586596127, sequence: 1420, offset: 80119
timestamp: 1586596127, sequence: 1420, offset: 80119
timestamp: 1586596128, sequence: 1421, offset: 81099
timestamp: 1586596128, sequence: 1421, offset: 81099
So, the kernel PPS subsystem is there and appears to be perfectly happy with the pps0 coming from /dev/ttyS0 but still GPSD appears unable to use all of that. |
|
