[LinuxPPS] unofficial Test patch for linux v2.6.30-rc6

[Hal V. Engel]

On Wednesday 20 May 2009 07:51:58 am William S. Brasher wrote:
> On Wed, 20 May 2009, Udo van den Heuvel wrote:
> > William S. Brasher wrote:
> > > The programs ppsldisc et al were compiled in the Document/pps directory
> >
> > (...)
> >
> > > The new, patched ntp-4.2.4p7 was also built with the new headers in
> > > place.
> >
> > Looks like you did the rigth things...
> >
> > > The first time I booted the new kernel and started ppsldisc I received
> > > that warning in the logs.  I have rebooted  that machine since then and
> > > both pps and ntp started on boot, and did not generate any warnings.
> >
> > Hmm. Maybe it is the similar thing to teh linux-kernel report that I
> > posted. Rodolfo also wrote it doesn't look LinuxPPS related.
> >
> > > That is actually a lot better that previous versions of the patch:  for
> > > some reason I've been unable to uncover, yet, ntp/pps tends to hang on
> > > my machines and require manual operator intervention to get started.
> >
> > That is strange.
> > What do you mean with 'hang'? Stops to respond completely?
> > Or? What happens, what doesn't? When?
> >
> > Kind regards,
> > Udo
>
> The daemon (ntp) seems to start, but it won't accept any connections.
> After booting a clock-box I have to log on, stop and restart ntp.  This
> later, manual, start works, leaving nothing in the logs to explain why ntp
> is not working.  I suspect ntp is trying to locate network interfaces, and
> they haven't come up, yet, when ntp is getting started.  I use Via 533 Mhz
> C3's for clocks, mostly, and udev takes a long time to report stuff like
> an interface coming up.
>
> Since ntp always starts manually, and I rarely shutdown or start a box
> running pps, I've ignored the problem.
>
> Of course, the fact that this has happened on boxes running linux 2.4
> and ntp 4.2.4p6 - and I never had the problem in past years with ntp on
> thoses boxes- really suggests ntp has a problem.

This looks like the problem originally reported by Reg and later confirmed by 
others including myself.  The problem is that for some reason NTP either does 
not see the PPS pulses or it sees the PPS pulses for a few seconds an then 
loses it (the later appears to be more common).  This problem only happens the 
first time NTP is started after a reboot and it does not matter if that first 
startup happens as part of the boot process or long after the machine has been 
started (I tested this).  A restart of NTP almost always works. 

This does not have anything to do with network interfaces and I am fairly 
certain that it is not UDEV related.  Adding delays for UDEV in the startup 
scripts did not help.   I "fixed" this on my machine by creating a new init 
script (/etc/init.d/ntp-pps in my case) that sets up line discipline, then 
starts ntp, then waits a while, then stops ntp and then repeats the process.  
This works 98% of the time but it is for sure a hack and it is also something 
that should not need to be done.

This issue is significant and appears to be more than just isolated to one or 
two machines.  It would be a major issue if there were not fairly simple  
workarounds.   But it does crop up fairly often and it causes a significant 
amount of confusion for new users.  This issue has been the subject of 
numerous threads here.   I think that it would be a good thing if this were 
fixed before kernel inclusion.   Of course the problem is that we have no idea 
what the root cause is at this point.

Hal