> That looks like a bug in whatever is feeding data to refclock_shm, > and possibly also an oversight in refclock_shm not checking that > it has a sensible precision value before passing it upwards.
Please open an issue at bugs.ntp.isc.org for the ntp product and the "refclock_shm" component if you believe this is a bug. > This also exposes a long-standing bug in ntpq.c\decodeint(), where > "&val" is used (twice) instead of "val", which screws-up display > of a zero precision value; eg: Please open an issue at bugs.ntp.isc.org for the NTP product and the "other" component for this. Thanks... H _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
