On 11/16/2011 23:06, Dave Hart wrote:
Ooops, see corrected suggested code:
On Thu, Nov 17, 2011 at 07:02, Dave Hart<[email protected]> 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.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
