[LinuxPPS] More 32-bit compatibility issues...

[George Spelvin]

Okay, after rebooting with that last patch, I get
ioctl32(ntpd:3438): Unknown cmd fd(5) cmd(c03c70a4){t:'p';sz:60} arg(ff8328d0) on /dev/pps0
ioctl32(ntpd:3438): Unknown cmd fd(5) cmd(c03c70a4){t:'p';sz:60} arg(ff8328d0) on /dev/pps0
ioctl32(ntpd:3438): Unknown cmd fd(5) cmd(c03c70a4){t:'p';sz:60} arg(ff8328d0) on /dev/pps0
ioctl32(ntpd:3438): Unknown cmd fd(5) cmd(c03c70a4){t:'p';sz:60} arg(ff8328d0) on /dev/pps0
ioctl32(ntpd:3438): Unknown cmd fd(5) cmd(c03c70a4){t:'p';sz:60} arg(ff8328d0) on /dev/pps0
ioctl32(ntpd:3438): Unknown cmd fd(5) cmd(c03c70a4){t:'p';sz:60} arg(ff8328d0) on /dev/pps0
ioctl32(ntpd:3438): Unknown cmd fd(5) cmd(c03c70a4){t:'p';sz:60} arg(ff8328d0) on /dev/pps0
ioctl32(ntpd:3438): Unknown cmd fd(5) cmd(c03c70a4){t:'p';sz:60} arg(ff8328d0) on /dev/pps0

The problem here is that struct pps_fdata is 64 bytes on a 64-bit machine,
but 60 bytes on a 32-bit one.  The extra 4 bytes are due to the fact
that the 32-bit x86 ABI only requires 32-bit alignment for 64-bit values,
so there is no padding at the end of struct pps_kinfo.

Style question: is it better to add
int _padding;
or 
__attribute__ ((aligned (8)))
to the struct pps_kinfo declaration?

Actually, I added the latter to struct pps_ktime, which will achieve the
same effect.  Now to recompile and reboot... oh, wait!  I dont have to
reboot; the (64-bit) kernel already has the alignment; it's only the
(32-bit) ntpd binary that needs rebuilding.


And... it works.  Sort of.

ntpd now successfully configures the PPS peer, but we still have the
earlier problem that running it freezes the pps device.

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.22.0    .PPS.            0 l    -    4    0    0.000    0.000   0.000
*127.127.29.0    .PALI.           0 l   12   16  377    0.000  -16.233   1.419
#216.53.131.200  208.75.88.4      3 u   43   64  377   51.498   12.248 168.914
-66.90.3.81      172.29.100.6     2 u   31   64  377   65.128   -0.059   6.520
 66.90.1.128     209.81.9.7       2 u   44   64  376   65.517   22.570 167.829
#129.174.93.11   66.187.224.4     2 u   53  256   37   66.252  -17.055   9.939
+63.119.46.3     .GPS.            1 u   60  256   37   59.469   -4.649   7.843
#66.115.136.4    130.207.244.240  2 u   57  256   37   70.406   -7.146   8.094
#66.250.45.2     209.51.161.238   2 u   48  256   37   58.026  -14.083   7.535
-64.90.182.55    .ACTS.           1 u   41  256   37   59.612   13.830  12.281
-64.236.96.53    .ACTS.           1 u   60  256   37   52.047    7.473  11.546
+130.207.244.240 .GPS.            1 u   35  256   37   73.648   -2.136   4.689
-198.72.72.10    65.212.71.103    2 u   38  256   37   71.139   -4.230   7.704
-192.5.41.41     .USNO.           1 u   48  256   37   61.346    1.033   6.143
#65.32.18.3      24.24.5.100      2 u   38  128  377   14.962    9.509  11.867
-65.32.18.4      24.24.5.100      2 u   44  128  377   14.500    1.168   6.224
#65.25.128.253   65.24.7.8        2 u   45  128  377   66.833   24.734   7.254

$ cat /sys/class/pps/pps0/[ac]*; sleep 10; cat /sys/class/pps/pps0/[ac]*
1225060052.014570726#75
1225060052.015561813#75
1225060052.014570726#75
1225060052.015561813#75

(Needless to say, the PPS signal worked fine for 75 seconds before ntpd
started.  I also verified that a simple "sleep 60 < /dev/pps0" didn't
cause any problems.)