On Thu, Nov 17, 2011 at 07:31, A C <[email protected]> wrote: > On 11/16/2011 23:06, Dave Hart wrote: > I will probably try this later on another identical system.
Please do. > 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. gpsd may still be easier, but depending on what you need, you might be able to stick with the NMEA driver and harvest the NMEA sentences ntpd uses from its clockstats file. > 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. Yes, I followed your saga on port-sparc. I'm still confused about why NMEA's PPSAPI support doesn't work using /dev/gpspps0 pointing to a different serial port than /dev/gps0, as it is then doing the same thing as NMEA + ATOM -- opening two ports, each only once. I understand why you would suspect as you do, but NMEA and ATOM really do use the same PPSAPI code, the only differences are how they number the seconds and how they open the PPS device. > PS: 4.2.7 with the C99 snprintf workaround is working fine. No crashes or > lockups. Now that is interesting, thanks for the info. Too often I don't hear when workarounds work, as there's no question burning in the mind of the person who had the problem once it's solved. That does seem to suggest a bug in the C runtime dtoa(), so if you want to track it down, a little test program which generates random doubles and dtoa()s them in a tight loop (printing their 64-bit hex dump first as two %lx's, four %lu's, or 8 %u's fed characters) might reveal a pattern to the inputs that send dtoa() into the infinite loop. Let me know if you want help writing such a test program. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
