> 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.