RTC usage bails out cleanly if accessing it goes wrong (e.g. HPET without generic RTC emulation)

This commit is contained in:
Richard Curnow 2005-07-19 21:22:52 +00:00 committed by Richard P. Curnow
parent 13ace061fa
commit 77da5b6144
3 changed files with 24 additions and 2 deletions

8
NEWS
View file

@ -1,3 +1,11 @@
New in version 1.21
===================
* Don't include Linux kernel header files any longer : allows chrony to compile
on recent distros.
* Stop trying to use RTC if continuous streams of error messages would occur
(Linux with HPET).
New in version 1.20
===================

View file

@ -836,7 +836,11 @@ compiled into the kernel). An estimate is made of the RTC error at a
particular RTC second, and the rate at which the RTC gains or loses time
relative to true time.
The RTC is fully supported in 2.2 and 2.4 kernels.
The RTC is fully supported in 2.2, 2.4 and 2.6 kernels.
On 2.6 kernels, if your motherboard has a HPET, you need to enable the
@samp{HPET_EMULATE_RTC} option in your kernel configuration. Otherwise, chrony
will not be able to interact with the RTC device and will give up using it.
For kernels in the 2.0 series prior to 2.0.32, the kernel was set up to
trim the RTC every 11 minutes. This would be disasterous for

View file

@ -867,9 +867,19 @@ read_from_device(void *any)
status = read(fd, &data, sizeof(data));
if (status < 0) {
/* This looks like a bad error : the file descriptor was indicating it was
* ready to read but we couldn't read anything. Give up. */
LOG(LOGS_ERR, LOGF_RtcLinux, "Could not read flags %s : %s", CNF_GetRtcDevice(), strerror(errno));
error = 1;
goto turn_off_interrupt;
SCH_RemoveInputFileHandler(fd);
switch_interrupts(0); /* Likely to raise error too, but just to be sure... */
close(fd);
fd = -1;
if (logfile) {
fclose(logfile);
logfile = NULL;
}
return;
}
if ((data & RTC_UIE) == RTC_UIE) {