[ntp:questions] refclock use causes core dump of ntpd

wa6zvp wa6zvp at gmail.com
Sat Feb 24 19:25:43 UTC 2007


On Feb 23, 3:43 am, Ronan Flood <use... at umbral.org.uk> wrote:
>
[snip]
> The e_Poll presumably needs to be there for t_goes, so the proper
> solution to this would seem to be to have e_Poll ignored where not
> expected.  It only seems to be t_unknown where that doesn't happen
> currently, so a simple fix like this might do the job:
>
> --- refclock_true.c.orig        Wed Feb 25 05:58:17 2004
> +++ refclock_true.c     Fri Feb 23 11:18:07 2007
> @@ -703,6 +703,8 @@
>                 }
>                 break;
>             case t_unknown:
> +               if (event == e_Poll)
> +                   break;
>                 switch (up->state) {
>                     case s_Base:
>                         if (event != e_Init)
>
> (Saves dealing with it in every case s_* within t_unknown)
>
> On the other hand, converting every abort() to break as you did
> to start with could be the right answer after all :-/
>
> --
> Ronan Flood <use... at umbral.org.uk>

* This patch works fine.  Thanks Ronan.

* I've decided to bite the bullet and modify the source to correctly
handle the TL-3 TrueTime receiver.
I've got a good enough handle on this driver now.

The TL-3 box can be placed in the 1-per-second timecode at will,
either from the serial port or via
the control panel.  When this driver encounters a _valid_ TrueTime
timecode on the serial port before it
has identifed the device, the state machine portion of the code
(true_doentry) can, and does get extremely confused.  It can actually
end up
in several different steady states, that after preventing aborts with
Ronan's patch, the driver will actually produce valid time to ntpd.
Right now, the driver actually thinks its an Omega receiver.:)

It should be able to identify the TL-3 if the auto output is not yet
turned on, and then proceed to turn on that mode and be happy.

I'm not sure I'll be able to unravel the unsolicited issue, but I'm
sure going to try.  It should be possible to continue the Inquiry
portion of
the code, while dealing with the ongoing incoming data.  Time will
tell.

* Attention Harlan, since there is no maintainer of this driver, is it
still possible for me to submit the changed code and get it into the
distribution?

73, Roger




More information about the questions mailing list