[chrony-dev] [PATCH v3] faq: Diagnose problem with RTC interrupts on Linux

[Michael Witten <mfwitten@xxxxxxxxx>]

Thanks for your patience.

This patch should achieve what you want; it provides only one change:
A new entry in the FAQ.

To apply this patch, save this email to /path/to/email, and then run:

  git am --scissors /path/to/email

Sincerely,
Michael Witten


Miroslav Lichvar wrote:

> You mean switch_interrupts() could succeed on start, but fail later?
> How could that happen?

I've never met a piece of hardware that is not a polished turd; indeed,
the existing code already tests BOTH enabling and disabling interrupts
(and 2 separate commits were made in order to achieve the test, because
the first attempt was not sufficient). Nothing Ever Works. Ever. It's
trash all the way down.

> Anyway, I suspect there might be other reasons for the ioctl to fail,
> e.g. a seccomp filter in some container, so to me it seems wrong to
> interpret that error message in the code, especially without checking
> the errno value. I'd just leave it as it is.

Regardless of the reason for the failure, the device either supports
the interrupts that chronyd needs, or it doesn't; in that sense, the
log message provided by the previous version of this patch makes no
special interpretation of the problem.

Nevertheless, that log message has been removed in this version.

>> +failure:
>> +  LOG(LOGS_WARN, "The RTC driver could not be initialised");
>> +  return 0;
>
> Please move this message to the caller in rtc.c and remove the "The".

I found there is no need; you yourself already created a log message
there:

  if (driver.init) {
    if ((driver.init)()) {
      driver_initialised = 1;
    }
  } else {
    LOG(LOGS_ERR, "RTC not supported on this operating system");
  }

> Also, please make the commit subject shorter.

Done.

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--

chronyd's Linux RTC driver (rtc_linux.c) requires the following ioctl
requests to be functional:

  RTC_UIE_ON
  RTC_UIE_OFF

However, a Linux system's RTC driver does not necessarily implement them,
as noted in these previous commits:

  d66b2f2b2423bfbd3de4d69895024dac7eefb306
  rtc: handle RTCs that don't support interrupts
  Tue Dec 10 17:45:28 2019 +0100

  bff3f51d13c3f41e2ead2cfff5bfe0b8c22ef44a
  rtc: extend check for RTCs that don't support interrupts
  Thu Dec 12 12:50:19 2019 +0100

Fortunately, the Linux kernel can be built with software emulation of
these hardware requests, by enabling the following config variable:

  CONFIG_RTC_INTF_DEV_UIE_EMUL
    Provides an emulation for RTC_UIE if the underlying rtc chip
    driver does not expose RTC_UIE ioctls. Those requests generate
    once-per-second update interrupts, used for synchronization.

    The emulation code will read the time from the hardware
    clock several times per second, please enable this option
    only if you know that you really need it.

This commit records these facts for the benefit of the user.
---
 doc/faq.adoc | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/doc/faq.adoc b/doc/faq.adoc
index 9d2c109..c09163e 100644
--- a/doc/faq.adoc
+++ b/doc/faq.adoc
@@ -597,6 +597,19 @@ things
 
 Some other program running on the system might be using the device.
 
+=== When I start `chronyd`, the log says `Could not enable RTC interrupt : Invalid argument` (or it may say `disable`)
+
+Your real-time clock hardware might not support the required ioctl requests:
+
+* `RTC_UIE_ON`
+* `RTC_UIE_OFF`
+
+A possible solution could be to build the Linux kernel with support for software
+emulation instead; try enabling the following configuration option when building
+the Linux kernel:
+
+* `CONFIG_RTC_INTF_DEV_UIE_EMUL`
+
 === What if my computer does not have an RTC or backup battery?
 
 In this case you can still use the `-s` option to set the system clock to the
-- 
2.22.0


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