[LinuxPPS] "...fetch/...timeout" but working anyways

[gnu not unix]

Hi again--

I went and patched ntp-dev again just to make sure I had things ok.
Had to make the same hand fix of one part of the nmea patch, but
no problem there. Then I started it up again. Well foo, I got the
same business in the dmesg log:


PPS event on source 0 at 1215356878.000407
capture assert seq #57196 for source 0
[IRQev] PPS assert at 5550845 on source #0
PPS event on source 0 at 1215356878.1356520
capture clear seq #57179 for source 0
[IRQev] PPS clear at 5550845 on source #0
PPS_FETCH: source 0
timeout 0.000000000
PPS_FETCH: source 0
timeout 0.000000000


Actually, though, I think the "timeout" is somehow misleading, because 
I let the patched ntpd run overnight, and here's my results:


gnu at nimbus.wraith.sf.ca.us[582] ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+GPS_NMEA(0)     .GPS.            0 l   45   64  377    0.000    0.000   0.000
oPPS(0)          .PPS.            0 l   13   16  377    0.000    0.000   0.000


Nice! Running an "ntpdate -d" against the friendly freebsd 5.4 box
gives me the following offset (line wrapped for email):

6 Jul 08:13:21 ntpdate[28935]: 
 adjust time server 192.58.220.65 offset -0.000014 sec

That is the same magnitude offset as the earlier linuxpps I
have running on another host here.

Also, here is what my syslog shows when I started up ntpd 
(lines wrapped for the email):


Jul  5 20:44:56 nimbus ntpd[28900]: 
     refclock_nmea: found GPS source "/dev/gps0"

Jul  5 20:44:56 nimbus ntpd[28900]: 
     refclock_nmea: try alternate PPS device "/dev/pps0"

Jul  5 20:44:56 nimbus ntpd[28900]: 
     refclock_nmea: found PPS source "/dev/pps0"

Jul  5 20:44:56 nimbus ntpd[28900]: 
     refclock_nmea: time_pps_kcbind failed: Operation not supported

So it looks like things are working well with the linuxpps patch
at the moment. The only issue is the kernel issue of the damaged
phase lock loop (pll) parameters, but that is not the linuxpps 
patch fault. This damage causes the terribly long time (hours) 
ntpd needs to process the initial offset adjustment. 

I am going to setup the parallel port pps now--I want to reboot
the test machine (nimbus) to fuss with the BIOS settings.


//Steve
ps I tried to resubscribe to the mailing list and "mailman" sent
an email claiming I was already subscribed. So email from the server
itself seems to get through, just nothing from the list subscription.