Bill Unruh [Tue, 26 Jun 2007 22:46:33 +0000 (23:46 +0100)]
Fix handling of stratum zero.
Further to the discussion with John Hasler, here are new diffs which
handles the incoming stratum 0 claim of a remote server by redefining the
incoming stratum as one bigger than the Max if it is zero, as per the NTP
version 4 documentation.
If the incoming stratum is zero it sets it to NTP_MAX_STRATUM+1 . If our
current stratum is larger than the NTP_MAX_STRATUM, the outgoing stratum is
also set to zero as per the suggestions in the NTP docs.
Introduces the new NTP_INVALID_STRATUM of 0 for doing these tests or
setting the outgoing stratum.
It is unclear whether chrony wants to follow NTP in setting the outgoing
stratum to zero if it is unknown or invalid, rather than a number larger
than the max stratum. Setting it to zero seems silly, since zero is already
used to define the stratum of a hardware clock (GPS, atomic, etc). This
seems ripe for confusion. But the fact that the ntp docs state to do this,
and that ntp servers (eg ntp.ubc.ca) are already doing this (using 0 to
mean invalid) means that chrony has to handle it on the incoming packets
from the servers.
Bill Unruh [Tue, 26 Jun 2007 22:42:11 +0000 (23:42 +0100)]
Fix problems with rtc_linux.
2) Changes to rtc_linux.c which a) do a double read of /dev/rtc when the
PPM interupt is turned on after the wait time expires. The current read
does not block to the second, as it should, thus two reads are needed.
Also, changes so that at startup the system properly ignores the last
system time from the initial burst mode for setting the system time since
it can be way off. At present this last system time is included in the
regression, which throws it off until finally that sample is dropped.
Stefan Lucke [Tue, 26 Jun 2007 22:02:33 +0000 (23:02 +0100)]
Fix sign v zero extension error in handling IP address
I switch to the git version of chrony. Accidently this version did not
talk to by lokal server at 192.168.192.4. Instead it continuosly tried
255.255.192.4 :-( .
Tracked that down to "char", "unsigned char" issue in nameserv.c:
kevin lyda [Fri, 14 Apr 2006 16:48:43 +0000 (17:48 +0100)]
Quash a load of compile warnings
Kevin Lyda writes:
I enclose the following patch which removes all but three of the warnings. i
don't have any non-linux systems handy to test a fix to the round() function.
but having it return a double should be fine.
It doesn't actually fix anything, it just shuts up -Wall, so it's certainly an
optional type of patch.
Eric Lammerts [Thu, 13 Apr 2006 15:15:26 +0000 (11:15 -0400)]
Fix bogus "system time" report for 64 bit systems
Eric Lammerts writes:
This is known as Debian bug #195620, which is almost three years old!
The problem is that a uint32_t which comes out of ntohl() (but
actually represents a signed value) is directly promoted to long.
Therefore no sign extension takes place.
Patch below solves the problem. There are other places where this
needs to be fixed, but I'll leave that to a less lazy person.
Bernhard Weiss [Sat, 24 Sep 2005 16:17:56 +0000 (18:17 +0200)]
Fix linux_io.h for MIPS
Bernard Weiss writes:
I managed to compile the chrony 1.21 package for the MIPS architecture.
For the package to compile I had to add the following lines to io_linux.h:
[patch]
These values are taken from the ioctl.h file of linux 2.4.30 for the MIPS arch
(__ASM_MIPS_IOCTL_H).
I tried to compile chrony-1.21 on FreeBSD 4.8-RELEASE & 5.4-RELEASE.
I modify two files, configure, sysinc.h.
configure:
add label "FreeBSD-i386" to "BSD/386" line
sysincl.h:
1. FreeBSD obsoletes alloca.h
2. FreeBSD use stdlib.h instead of malloc.h, to use malloc(), free()
Paul Elliott [Mon, 5 Dec 2005 07:16:26 +0000 (01:16 -0600)]
Flush chronyc output buffers.
The following is a patch to chronyc that causes it
to flush the buffers to stderr and stdout after
executing each command. This is needed if
you are controling chronyc from a program (i.e. chronyc's
input and output descriptors are pipes which are being
written/read by another program) and
you do not want to block waiting for chronyc response
which is trapped in a buffer!
John Hasler sent in a patch to do this (which still wouldn't make it compile
for me). This reminded me that I had tackled this myself when my distro moved
to gcc-4 a while back. It turned out I had never even checked in the file from
the working copy I was using (!). Anyway, here it is now.
This is a verbatim copy of the files at that stage of the repository that was
built from the CVS import. It allows future development to see a bit of recent
history, but without carrying around the baggage going back to 1997. If that
is really required, git grafts can be used.