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

["Hattink, Tjalling [FINT]" <T.Hattink@xxxxxxxx>]

> 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-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.