Bug 242891 - ntp can not 1PPS with gpsd on F7, but did on FC6
Summary: ntp can not 1PPS with gpsd on F7, but did on FC6
Status: CLOSED DUPLICATE of bug 243026
Alias: None
Product: Fedora
Classification: Fedora
Component: gpsd   
(Show other bugs)
Version: 7
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Matthew Truch
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-06 09:24 UTC by David
Modified: 2007-11-30 22:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-01 12:34:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
gpsd full diag log (524.05 KB, application/octet-stream)
2007-06-07 12:21 UTC, David
no flags Details

Description David 2007-06-06 09:24:57 UTC
Description of problem:
On F7 ntp can not work 1PPS together with gpsd.  On FC6 and stock kernel, with
the serial DCD line connected to a GPS receiver with 1PPS support, ntpq -p happy
reported that * (primary) was from SHM(1) .GPS1. and + (secondary) was from
SHM(0) .GPS.

However since upgrading to F7 it refuses to work 1PPS, it only locks * (primary)
 from SHM(0) .GPS.

There is too much gitter without 1PPS for precise time server use and it needs
to be fixed.

I filled bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242211 but
told its not the kernel and the bug is still there and no one is fixing the issue.

As gpsd is the same source for F7 as was with FC6, the problem has to be ntp.

Version-Release number of selected component (if applicable):

How reproducible:
1PPS worked with FC6 and now does not with F7, hardware is the same, config
files everything.

Steps to Reproduce:
Actual results:
No 1PPS support

Expected results:
1PPS support

Additional info:

Comment 1 Miroslav Lichvar 2007-06-06 10:08:09 UTC
Does ntpd from the FC-6 package have the same problem?

Comment 2 David 2007-06-06 10:40:16 UTC
Thanks for the reply.  No on FC6 no issue at all, ntpd happily uses the 1PPS
output from gpsd.

Its one of three things in F7, kernel, ntpd or gpsd.

Its the same computer and config files for gpsd and ntp, so hardware has not
changed, just its gone from FC6 to F7.

I naturally had to set selinux to permissive until my other bug of needing a
ntpd policy added to selinux on F7, so you can run enforcing, but ntpd will sync
to gpsd.

Anything else you need?

Comment 3 Miroslav Lichvar 2007-06-06 10:50:57 UTC
Yes. I'm not sure if you have already tried, but I need to know if FC-6 ntp is
ok on F-7.

Please downgrade ntp to FC-6 (ntp-4.2.4p0-1.fc6) and see if it's better. If it
works ok, it's a problem in ntp.

Comment 4 David 2007-06-06 11:16:03 UTC
no problems can do, how do I downgrade ntp to fc6 and then back to f7?

I downloaded the rpms...

Comment 5 Miroslav Lichvar 2007-06-06 11:27:33 UTC
rpm -U --oldpackage ntp-4.2.4p0-1.fc6.i386.rpm

and back to F-7 ntp:
rpm -U ntp-4.2.4p0-2.fc7.i386.rpm (or just yum update)

Comment 6 David 2007-06-06 11:28:54 UTC
[root@primary ~]# rpm --oldpackage ntp-4.2.4p0-1.fc6.i386.rpm
rpm: only installation, upgrading, rmsource and rmspec may be forced
[root@primary ~]#

Comment 7 David 2007-06-06 11:31:23 UTC
Sorry typo, I forgot the -U

I just did it awaiting ntpd to sync up.

Nope its still not locking on the 1PPS :(

[root@primary ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
*SHM(0)          .GPS.            0 l   18   16   17    0.000    9.149   1.294
 SHM(1)          .GPS1.           0 l    -   16    0    0.000    0.000   0.001
 x1.tonyurban.co     3 u   63   64    1  233.992  -163.63   0.001
 dake.desynched.      2 u   62   64    1  226.602  -153.59   0.001
 silk.lonewander      3 u   61   64    1  175.674  -275.82   0.001   .BCST.          16 u    -   64    0    0.000    0.000   0.001  .BCST.          16 u    -   64    0    0.000    0.000   0.001
 NTP.MCAST.NET   .MCST.          16 u    -   64    0    0.000    0.000   0.001
 LOCAL(0)        .LOCL.          10 l   57   64    1    0.000    0.000   0.001
[root@primary ~]#

Comment 8 David 2007-06-06 11:44:30 UTC
I also checked, the gpsd package is for fc7

Installed Packages
gpsd.i386                                2.34-3.fc7             installed

Back now to the f7 ntp version, its just the same as the above fc6 ntp.

[root@primary etc]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
*SHM(0)          .GPS.            0 l    9   16  377    0.000    0.147   1.788
 SHM(1)          .GPS1.           0 l    -   16    0    0.000    0.000   0.001
+x1.tonyurban.co     3 u    4   64   37  234.519  -168.48   1.155
+ns37256.ovh.net  3 u    4   64   37  319.186  -170.57   0.538
 silk.lonewander      3 u    -   64   27  175.565  -336.31  15.469   .BCST.          16 u    -   64    0    0.000    0.000   0.001  .BCST.          16 u    -   64    0    0.000    0.000   0.001
 NTP.MCAST.NET   .MCST.          16 u    -   64    0    0.000    0.000   0.001
 LOCAL(0)        .LOCL.          10 l   60   64   17    0.000    0.000   0.001

Can you read my bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242211

I say it has to be the kernel as someone said there are timekeeping changes in
it.  Can we get that bug reopened?

There is something broken in F7 as it used to work and how it does not.  Let me
know any files you need.

Here is the extract from my ntp.conf, but this iks timestamped from fc6 and I
know its untouched and worked...

# Use GPSD
server minpoll 4 maxpoll 4
fudge time1 0.000 refid GPS
server minpoll 4 maxpoll 4 prefer
fudge refid GPS1

We know GPSD works, I get broadcasts and ntp is happy enough to use it, just the
1PPS is not working.

Comment 9 Miroslav Lichvar 2007-06-06 15:28:50 UTC
Then it doesn't look like a bug in ntpd.

If I understand how gpsd works correctly, it doesn't use PPS API of kernel but
interprets pulses emitted on port itself. Maybe running gpsd -D 5 would show if
PPS is detected?

Comment 10 David 2007-06-06 22:15:29 UTC
Yes that is correct how the 1PPS is detected.

I better file a bug against gpsd, as you said its not looking like ntpd.

Comment 11 David 2007-06-06 22:32:21 UTC
I filled bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243026 for gpsd.

Do you think a serial port bug, where the pulsing DCD line is not getting detected?

Comment 12 Miroslav Lichvar 2007-06-07 11:09:18 UTC
Do you see any pps messages when the following command is started?

/usr/sbin/gpsd -n -N -D 5 /dev/ttyS0 2>&1 | grep -i pps

Also you could try statserial /dev/ttyS0, if you can see changing status on DCD.

Comment 13 David 2007-06-07 12:21:54 UTC
Created attachment 156453 [details]
gpsd full diag log

You can see the PPS messages but while its still trying to sync.  Once it has
synced its stopped.

So a bug in gpsd!

Comment 14 Matthew Truch 2007-06-07 19:49:51 UTC
(In reply to comment #13)
> Created an attachment (id=156453) [edit]
> gpsd full diag log
> You can see the PPS messages but while its still trying to sync.  Once it has
> synced its stopped.
> So a bug in gpsd!

Which is very strange, as gpsd has not changed at all (other than a recompile)
for F7.  I'm at a loss on how to fix gpsd given there was no change.

Comment 15 David 2007-06-07 22:40:55 UTC
There is obviously some change in F7 that gpsd needs to take into account so it
works properly :(

I opened a bug for gpsd as it has a bug in F7.


As you can see in the gpsd diag, its detecting the DCD 1PPS early on as its
syncing up, then gives up and does not try again by the time its running 4800
nmea mode.

Comment 16 David 2007-08-01 07:13:51 UTC
Thanks to some amazing help from Mick we proved it was gpsd at fault and
compiled a working gpsd with PPS support for F7

Comment 17 Matthew Truch 2007-08-01 12:34:22 UTC
This was originally the ntp bug for this issue; but there is already a gpsd bug
for this issue, so marking it as a dupe (so there's only one open report).  

*** This bug has been marked as a duplicate of 243026 ***

Note You need to log in before you can comment on or make changes to this bug.