On Tue, Dec 10, 2019 at 12:20 PM Miroslav Lichvar <[email protected]>
wrote:
> 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 [email protected] with
> "unsubscribe" in the subject.
> For help email [email protected] with "help" in the
> subject.
> Trouble? Email [email protected].
>
>
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
