On Wed, May 28, 2014 at 02:52:54PM +0200, Hattink, Tjalling [FINT] wrote: > When the kernel rtc driver queries the rtc it has to issue multiple read > operations to get the data. It first reads the seconds, then minutes, > hours, etc.. You can see this happening in the kernel 3.10.34 at > drivers/char/rtc.c:1323-1331 > > The problem is that between these read operations the rtc hardware could > update itself by adding a second.
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(); > 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 got it from > https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/sys-uti > ls/hwclock-cmos.c?h=stable/v2.24 > From line 518-553. In here you also see a while loop, and the seconds > checked at line 551 Ok, but that's used when CMOS is read directly, not with the RTC_RD_TIME ioctl. The patch looks good to me, I just want to be sure I understand when can this happen. 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.