On Fri, Dec 06, 2019 at 12:35:21PM +0100, Christian Ehrhardt wrote:
> To summarize:
> - RTC init fails
> - SCH_MainLoop then hangs
> Could the second be a consequence of the first?
> Does this make sense to anyone?
It seems the RTC interrupts cannot be enabled. As Vincent suggests
this is probably due to the HW/driver.
With the -s option chronyd waits for the clock to be adjusted by RTC,
but that doesn't happen because there are no interrupts.
As a fix, I think we can change the error message to be fatal.
--- a/rtc_linux.c
+++ b/rtc_linux.c
@@ -566,8 +566,7 @@ switch_interrupts(int onoff)
if (onoff) {
status = ioctl(fd, RTC_UIE_ON, 0);
if (status < 0) {
- LOG(LOGS_ERR, "Could not %s RTC interrupt : %s", "enable", strerror(errno));
- return;
+ LOG_FATAL("Could not %s RTC interrupt : %s", "enable", strerror(errno));
}
skip_interrupts = 1;
} else {
Although, I'm not sure if we shouldn'd limit that just to the -s
option. Some users might have enabled rtcfile with such an RTC and
they have syslog full of error messages, but chronyd should otherwise
be working as expected.
As for the rtc system test, it should be modified to detect an RTC
which doesn't support interrupts and skip the test. I'm not sure how.
Does hwclock -r show anything interesting on this RTC?
I was checking rtc output in dmesg and hwclock, nothing was suspicious to me at this level.
Working:
x86 KVM
$ dmesg | grep -i rtc
[ 0.557822] PM: RTC time: 11:57:17, date: 2019-12-10
[ 1.765930] rtc_cmos 00:00: RTC can wake from S4
[ 1.769633] rtc_cmos 00:00: registered as rtc0
[ 1.772179] rtc_cmos 00:00: alarms up to one day, y3k, 114 bytes nvram, hpet irqs
[ 1.970044] rtc_cmos 00:00: setting system clock to 2019-12-10T11:57:18 UTC (1575979038)
$ sudo hwclock -r
2019-12-10 13:20:53.870726+00:00
armhf emulated in qemu
$ dmesg | grep -i rtc
[ 6.718918] rtc-pl031 9010000.pl031: registered as rtc0
[ 14.019679] rtc-pl031 9010000.pl031: setting system clock to 2019-12-10T12:27:16 UTC (1575980836
$ sudo hwclock -r
2019-12-10 13:21:47.949155+00:00
Failing
arm64 KVM
$ dmesg | grep -i rtc
[ 0.876198] rtc-efi rtc-efi: registered as rtc0
[ 1..046869] rtc-efi rtc-efi: setting system clock to 2019-12-10T11:44:59 UTC (1575978299)
$ sudo hwclock -r
2019-12-10 13:20:25.467829+00:00
$ dmesg | grep -i rtc
[ 0.241872] rtc-generic rtc-generic: registered as rtc0
[ 0.270221] rtc-generic rtc-generic: setting system clock to 2019-12-06T08:18:19 UTC (1575620299)
$ sudo hwclock -r
2019-12-10 13:22:47.968726+00:00
So far the test only checks if it exists test/system/101-rtc:
[ -c "/dev/rtc" ] || test_skip "missing /dev/rtc"
I was checking the options of hwclock further and found the following to work:
$ sudo hwclock -r --test | grep '^ioctl.*RTC_UIE_ON.*Invalid argument$'
--test implies --verbose and in fact it tries to enable RTC_UIE_ON and reports if that fails.
Probably better than writing a custom ioctl tool for that.
The full output is something like:
$ sudo hwclock -r --test
hwclock from util-linux 2.34
System Time: 1575984608.231551
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
ioctl(4, RTC_UIE_ON, 0): Invalid argument
Waiting in loop for time from /dev/rtc0 to change
...got clock tick
Time read from Hardware Clock: 2019/12/10 13:30:10
Hw clock time : 2019/12/10 13:30:10 = 1575984610 seconds since 1969
Time since last adjustment is 1575984610 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2019-12-10 13:30:09.229564+00:00
Test mode: nothing was changed.
I have a fix that works locally, but I'll do a bigger loop of packaging/rebuild/retest before submitting.
--
Miroslav Lichvar
--
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.