[ntp:questions] Ignore one server except in extreme conditions?

A C agcarver+ntp at acarver.net
Thu Nov 17 07:31:04 UTC 2011


On 11/16/2011 23:06, Dave Hart wrote:
> Ooops, see corrected suggested code:
>
> On Thu, Nov 17, 2011 at 07:02, Dave Hart<hart at ntp.org>  wrote:
>> change the if block to:
>>
>>         if (-1 == pps_fd) {
>>                 pps_fd = pp->io.fd;
>>                 msyslog(LOG_WARNING, "%s cannot open %s: %d %m",
>>                         refnumtoa(&peer->srcadr), errno);
>>         }
>>
>> And try again, so we can narrow down the reason for the failure.
>
> That should be:
>
>          if (-1 == pps_fd) {
>                  pps_fd = pp->io.fd;
>                  msyslog(LOG_WARNING, "%s cannot open %s: %d %m",
>                          refnumtoa(&peer->srcadr), device, errno);
>          }
>
> The version above left out device.  There is still one more format
> specifier than argument, %m, but it doesn't consume an argument.
>
> Red faced,
> Dave Hart

I will probably try this later on another identical system.  I'm going 
to switch to a shared memory driver because my eventual desire was to 
have gpsd running to collect position and timing data to use for another 
experiment.  But that requires SiRF binary mode which precludes using 
the NMEA driver.   I have all the hardware required to create a 
duplicate system, I just need a bit of time to do it.  I may also have 
to try and find a couple SBUS serial cards and see if things work any 
better with them.

I am mostly convinced that the lack of PPS on the NMEA driver comes down 
to the NetBSD serial driver on sparc hardware not behaving quite right, 
close but not quite right.  Kernel PPS behaves the same way, I can't use 
a serial port for kernel PPS and also pull serial data through it 
simultaneously, the PPS disappears.  But if I run the PPS into a port 
all by itself and never try to read data from the port, it's fine. 
That's why I ended up leaving the ports split, it just worked properly 
at that point.  Otherwise trying to use the port twice (once to get DCD 
signals and once for the TX/RX data) fails.



PS: 4.2.7 with the C99 snprintf workaround is working fine.  No crashes 
or lockups.


More information about the questions mailing list