[ntp:questions] ntpd connect gpsd shared memory driver

Richard Cagley rcagley at gmail.com
Tue Jun 18 19:44:40 UTC 2013


On Tue, Jun 18, 2013 at 11:28 AM, Rob <nomail at example.com> wrote:

> Well, gpsd does not use kernel pps.  It puts the pps time into the
> second SHM segment and lets ntpd pick it up there.  This was coded
> in the days that Linux kernels often came without pps support and
> additional patches would have to be applied.
> I'm not too familiar with kernel pps or how you tell the kernel where
> to look for the pps, and if this can interfere with gpsd.
> Maybe gpsd has been updated to recognize kernel pps and stay out of
> the way, but it does not look like it in your debug log.
> (it still creates the pps thread)
> I would try removing the kernel pps config while you use gpsd, or only add
> it after it has been shown to work without it.
>
> Strang that this is the last that is heard from PPS, while in your
> earlier log there were a few PPS pulses that looked OK.
> (but then they were not used because no valid serial data was coming in)
> Did you change something?
>

Yeah, it's a huge mystery to me how the kernel is getting pps info without
me even telling it where the pin is. I can build in kernel pps support and
debug output and see messages ever second on the console without ever
explicitly doing an ldattach to /dev/ttyO0. I'm using the DCD pin, which I
think is default. Maybe the kernel can generate it's own pps signaling, but
I don't think it can. I'm using plain jane pps source out of the 2.6.37
kernel.


The output you refer to may be partial. I do see lots of NMEA data.


More information about the questions mailing list