[chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 1.29.1-169-gcea68eb

2014-06-02 Thread git 
This is an automated email from git. It was enerated because a ref
change was pushed to the repository "chrony/chrony.git".

The branch, master has been updated
   via  cea68ebc6fa4a7add9cb3bbd428cff80875eba32 (commit)
   via  a33a955163c1af459af176b3fdc1c4c56b4f25f3 (commit)
   via  a3e60c93da7e216ff76f72f73ed33775be369ede (commit)
   via  44c9744d69b2e116d7881ad5413f27fe1812ed89 (commit)
   via  b69b648d1879a1e32c40fbb8ccacd890fadc3813 (commit)
   via  3ebebac695087f19b90e2d528534550655de9b48 (commit)
   via  13d734c8d26054ddf329d8dba64365d29709df3c (commit)
   via  c903c5f72bb3001af30cd15458afafbb0089b962 (commit)
   via  b03c7581f2968449cc2a7057c11d3531e3c61652 (commit)
   via  2ed9853bcc6a2e75749dd8a8153cdfb9efd8b236 (commit)
  from  26e00ffbeb608f43106fec96c94629dbe74e87fd (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit cea68ebc6fa4a7add9cb3bbd428cff80875eba32
Author: Miroslav Lichvar 
List-Post: chrony-dev@chrony.tuxfamily.org
Date:   Mon Jun 2 18:22:48 2014 +0200

test: extend 005-externalstep

commit a33a955163c1af459af176b3fdc1c4c56b4f25f3
Author: Miroslav Lichvar 
List-Post: chrony-dev@chrony.tuxfamily.org
Date:   Mon Jun 2 17:14:28 2014 +0200

local: reset daemon after unexpected time jump

Add a new change type and use it when an unexpected time jump is
detected in the scheduler to reset reference times, offset and slewing,
NCR instances (with their polling interval), synchronization status, and
drop all sourcestats, manual, refclock and RTC samples.

This should make the recovery more graceful if the estimated jump has a
large error (e.g. select didn't timeout, or after system suspend).

commit a3e60c93da7e216ff76f72f73ed33775be369ede
Author: Miroslav Lichvar 
List-Post: chrony-dev@chrony.tuxfamily.org
Date:   Fri May 30 17:30:02 2014 +0200

sched: try to detect also forward time jumps

commit 44c9744d69b2e116d7881ad5413f27fe1812ed89
Author: Miroslav Lichvar 
List-Post: chrony-dev@chrony.tuxfamily.org
Date:   Fri May 30 13:02:45 2014 +0200

local: replace is_step_change parameter of change handler with enum

Prepare for a new change type that will be added later.

commit b69b648d1879a1e32c40fbb8ccacd890fadc3813
Author: Miroslav Lichvar 
List-Post: chrony-dev@chrony.tuxfamily.org
Date:   Fri May 30 14:46:46 2014 +0200

local: refactor invocation of parameter change handlers

commit 3ebebac695087f19b90e2d528534550655de9b48
Author: Miroslav Lichvar 
List-Post: chrony-dev@chrony.tuxfamily.org
Date:   Fri May 30 17:04:10 2014 +0200

ntp: reset NCR instance thoroughly when switching to offline

commit 13d734c8d26054ddf329d8dba64365d29709df3c
Author: Miroslav Lichvar 
List-Post: chrony-dev@chrony.tuxfamily.org
Date:   Mon Jun 2 16:30:12 2014 +0200

sourcestats: reset SST instance thoroughly when dropping samples

commit c903c5f72bb3001af30cd15458afafbb0089b962
Author: Miroslav Lichvar 
List-Post: chrony-dev@chrony.tuxfamily.org
Date:   Thu May 29 18:43:11 2014 +0200

sourcestats: remove forgotten declaration

commit b03c7581f2968449cc2a7057c11d3531e3c61652
Author: Miroslav Lichvar 
List-Post: chrony-dev@chrony.tuxfamily.org
Date:   Fri May 30 16:12:02 2014 +0200

configure: fix test code to be compilable with -Werror

commit 2ed9853bcc6a2e75749dd8a8153cdfb9efd8b236
Author: Hattink, Tjalling [FINT] 
List-Post: chrony-dev@chrony.tuxfamily.org
Date:   Wed May 28 13:54:27 2014 +0200

rtc: more reliable method of reading rtc for initial trim

When chrony reads in the linux rtc for the first time to trim the system
clock, it only reads it once. As it is possible that the rtc updates
itself during the read operation, the reported rtc time could be false.
To prevent this I've added a loop that reads the rtc clock twice, if the
seconds do not match retry the two read operations. If they match you
can assume the read operation was successful.

This is based on the hwclock implementation of reading the rtc clock
from the util-linux package.

---

Summary of changes:
 configure|4 +-
 local.c  |   43 +++--
 local.h  |   12 +--
 manual.c |9 -
 ntp_core.c   |   66 --
 ntp_core.h   |3 ++
 ntp_sources.c|   10 --
 refclock.c   |   12 --
 reference.c

Re: [chrony-dev] [PATCH] More reliable method of reading rtc for initial trim

2014-06-02 Thread Miroslav Lichvar 
On Mon, Jun 02, 2014 at 11:48:13AM +0200, Hattink, Tjalling [FINT] wrote:
> > > I've been able to see this behavior by continuously reading the rtc
> > > clock.
> > 
> > Was that with the RTC_RD_TIME ioctl or were you reading CMOS directly?
> > I tried to reproduce it with a program continuosly reading the RTC
> with
> > the ioctl, I let it run overnight, but it didn't report any occurence
> > of the problem.
> > 
> 
> I was using the ioctl path. Maybe some CMOS implementations (my board in
> this case) are more susceptible for this problem than others. Hard to
> say.

Ok, I'll push the patch to git. Thanks.

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

RE: [chrony-dev] [PATCH] More reliable method of reading rtc for initial trim

2014-06-02 Thread Hattink, Tjalling [FINT] 
> Isn't the following code in the kernel code (above the CMOS
> operations) supposed to prevent that?
> 
>   /*
>* read RTC once any update in progress is done. The update
>* can take just over 2ms. We wait 20ms. There is no need to
>* to poll-wait (up to 1s - eeccch) for the falling edge of
> RTC_UIP.
>* If you need to know *exactly* when a second has started,
> enable
>* periodic update complete interrupts, (via ioctl) and then
>* immediately read /dev/rtc which will block until you get the
> IRQ.
>* Once the read clears, read the RTC time (again via ioctl).
> Easy.
>*/
> 
>   while (rtc_is_updating() != 0 &&
>  time_before(jiffies, uip_watchdog + 2*HZ/100))
>   cpu_relax();
> 

This code does catch the situation that when the RTC is busy updating
itself when the request for time is issued. It will wait until the RTC
reports being updated. But it doesn't catch the situation when the
request for time is issued right before the RTC is about to update
itself. The while loop will go through and the kernel starts to read in
the first bytes. Then the RTC decides to update itself and the kernel
will read in the wrong values for subsequent bytes. I know, it is an
unlikely race condition, but it could still hurt chrony when the readout
is wrong.

> > I've been able to see this behavior by continuously reading the rtc
> > clock.
> 
> Was that with the RTC_RD_TIME ioctl or were you reading CMOS directly?
> I tried to reproduce it with a program continuosly reading the RTC
with
> the ioctl, I let it run overnight, but it didn't report any occurence
> of the problem.
> 

I was using the ioctl path. Maybe some CMOS implementations (my board in
this case) are more susceptible for this problem than others. Hard to
say.

Best regards,

Tjalling Hattink

--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.