Re: [chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On Wed, Dec 11, 2019 at 05:42:12PM +0100, Miroslav Lichvar wrote: > On Wed, Dec 11, 2019 at 04:13:23PM +0100, Christian Ehrhardt wrote: > > That means the first switch_interrupts call from RTC_Initialise -> > > RTC_Linux_Initialise -> switch_interrupts has on_off=0 and that doesn't > > trigger the issue at initialization phase. > > Later on on RTC_TimeInit -> switch_interrupts argument on_off=1 and the > > issue occurs. > > Turns out our "problematic" RTCs only trigger the issue on on_off=1. > > Interesting. When I added that code I checked the kernel source code > and it looked like enabling and disabling the interrupt should both > return the same error. Looking at the kernel code more carefully, it seems it checks whether the state is changing before checking if UIE is actually supported, so switch_interrupts(0) would fail only if interrupts were already "enabled" (which they cannot be). Testing both, as you did in your patch, is the correct fix. -- Miroslav Lichvar -- 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.
Re: [chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On Wed, Dec 11, 2019 at 5:42 PM Miroslav Lichvar
wrote:
> On Wed, Dec 11, 2019 at 04:13:23PM +0100, Christian Ehrhardt wrote:
> > That means the first switch_interrupts call from RTC_Initialise ->
> > RTC_Linux_Initialise -> switch_interrupts has on_off=0 and that doesn't
> > trigger the issue at initialization phase.
> > Later on on RTC_TimeInit -> switch_interrupts argument on_off=1 and the
> > issue occurs.
> > Turns out our "problematic" RTCs only trigger the issue on on_off=1.
>
> Interesting. When I added that code I checked the kernel source code
> and it looked like enabling and disabling the interrupt should both
> return the same error.
>
> What RTC driver is used on the machine?
>
I think I mentioned this before, the two failing ones are:
PPC64
# 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)
ARM64
# 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)
> >/* Make sure the RTC supports interrupts */
> > - if (!switch_interrupts(0)) {
> > + if (!switch_interrupts(1) || switch_interrupts(0)) {
> > close(fd);
> > return 0;
> >}
>
> I'd prefer this approach, but I think there is a missing "!" before
> the second call of switch_interrupts().
>
Agreed
With that it behaves like the following (hang fixed):
# ./run -d 101-rtc
101-rtc Testing real-time clock:
non-default settings:
extra_chronyd_directives=rtcfile
/home/ubuntu/chrony/test/system/tmp/rtcfile
extra_chronyd_options=-s
minimal_config=1
starting chronyd OK
stopping chronyd OK
checking message "\(clock off from RTC\|RTC time before last\)" BAD
FAIL
SUMMARY:
TOTAL 1
PASSED 0
FAILED 1(101-rtc)
SKIPPED 0 ()
root@bos01-ppc64-chrony-adt-issue:/home/ubuntu/chrony/test/system# tail -n
20 tmp/*
==> tmp/chronyd.conf <==
pidfile /home/ubuntu/chrony/test/system/tmp/chronyd.pid
bindcmdaddress /home/ubuntu/chrony/test/system/tmp/chronyd.sock
port 17575
cmdport 14432
rtcfile /home/ubuntu/chrony/test/system/tmp/rtcfile
==> tmp/chronyd.log <==
2019-12-12T07:20:35Z chronyd version DEVELOPMENT starting (+CMDMON +NTP
+REFCLOCK +RTC +PRIVDROP -SCFILTER -SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
2019-12-12T07:20:35Z Disabled control of system clock
2019-12-12T07:20:35Z Could not enable RTC interrupt : Invalid argument
2019-12-12T07:20:35Z chronyd exiting
==> tmp/chronyd.out <==
==> tmp/driftfile <==
0.0 1
==> tmp/keys <==
1 MD5 abcdefghijklmnopq
==> tmp/rtcfile <==
1 1576135235 0.0 0.0
==> tmp/tempcomp <==
0.0
> I've understood that you wanted it to hard-fail and bail out of -s was set
> > but RTC init failed right?
>
> No, it should continue to run (using other time sources as configured).
>
Thanks for explaining that - that seems correct for the general case
(outside of the tests).
But that still means the test would flag "chrony broken" for test 101-rtc
in places where we know the reason are RTC clocks not supporting an option.
I'd suggest to also add the initial patch I had that skips the test in
those cases.
I'll send a v2 (for internationalization) and add a commit for
the switch_interrupts 0+1 as discussed above
--
> Miroslav Lichvar
>
>
> --
> 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.
>
>
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
Re: [chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On Wed, Dec 11, 2019 at 04:13:23PM +0100, Christian Ehrhardt wrote:
> That means the first switch_interrupts call from RTC_Initialise ->
> RTC_Linux_Initialise -> switch_interrupts has on_off=0 and that doesn't
> trigger the issue at initialization phase.
> Later on on RTC_TimeInit -> switch_interrupts argument on_off=1 and the
> issue occurs.
> Turns out our "problematic" RTCs only trigger the issue on on_off=1.
Interesting. When I added that code I checked the kernel source code
and it looked like enabling and disabling the interrupt should both
return the same error.
What RTC driver is used on the machine?
>/* Make sure the RTC supports interrupts */
> - if (!switch_interrupts(0)) {
> + if (!switch_interrupts(1) || switch_interrupts(0)) {
> close(fd);
> return 0;
>}
I'd prefer this approach, but I think there is a missing "!" before
the second call of switch_interrupts().
> I've understood that you wanted it to hard-fail and bail out of -s was set
> but RTC init failed right?
No, it should continue to run (using other time sources as configured).
--
Miroslav Lichvar
--
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.
Re: [chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On Wed, Dec 11, 2019 at 4:24 PM Vincent Blut wrote: > On 2019-12-11T16:13+0100, Christian Ehrhardt wrote: > >On Tue, Dec 10, 2019 at 5:59 PM Miroslav Lichvar > >wrote: > > > >> On Tue, Dec 10, 2019 at 04:25:31PM +0100, Christian Ehrhardt wrote: > >> > On Tue, Dec 10, 2019 at 4:19 PM Miroslav Lichvar > > >> > > I'm sorry for changing my mind, but I now think this case should be > >> > > handled gracefully in chronyd and not avoided in the test. According > >> > > to the man page, the -s option is supposed to work even with no RTC > or > >> > > broken RTCs. A hang or fatal error with the -s option may break > >> > > the user's expectation. > >> > > > >> > > Do you agree? > >> > > > >> > > >> > Yes, but I think the changes are not mutually exclusive and should > both > >> be > >> > added. > >> > > >> > -s needs the change you suggested to make the fail fatal. > >> > >> As I tried to explain in the later post, I think chronyd -s should not > >> fail if the RTC doesn't support interrupts, as the documentation > >> implies chronyd can work with "broken" RTCs and we shouldn't expect > >> the users to test it before configuring chronyd. > >> > >> > Otherwise users will not realize that they don't get what they > ordered. > >> > >> There will still be the error message in the log. > >> > >> Can you please try the test again with the latest code? > >> > > > >I tested with the current head being commit f5eb7daf "rtc: disable > >interrupts in finalization" > > > >With that the test finally worked on the two affected platforms that I > had: > >./run -d 103-refclock > >103-refclock Testing reference clocks: > > non-default settings: > >extra_chronyd_directives= refclock SOCK > >/home/ubuntu/chrony/test/system/tmp/refclock.sock refclock SHM 100 > > starting chronyd OK > > waiting for synchronization OK > > stopping chronyd OK > > checking chronyd messages OK > > checking chronyd filesOK > >PASS > > > > > >SUMMARY: > > TOTAL 1 > > PASSED 1 > > FAILED 0() > > SKIPPED 0 () > > What about the 101-rtc test, Christian? ;-) > Hehe, silly typo while tabbing commands - yeah you are right. 101 still fails the same way, and thereby matching the -d check. I have rebuilt and rerun the test twice, but above issue remains. arm64 and ppc64el behave the same way on this. Fortunately all the debugging info of above still is correct and might still help to get closer to a final fix. BTW - on debugging you have to be careful, the following checking message "\(clock off from RTC\|RTC time before last\)" BAD means there likely is a stale chrony process test left from a former test. BTW after the failing 101-rtc test the files in tmp say: # head -n 20 tmp/* ==> tmp/chronyd.conf <== pidfile /home/ubuntu/chrony-ubuntu-git/test/system/tmp/chronyd.pid bindcmdaddress /home/ubuntu/chrony-ubuntu-git/test/system/tmp/chronyd.sock port 16097 cmdport 13626 rtcfile /home/ubuntu/chrony-ubuntu-git/test/system/tmp/rtcfile ==> tmp/chronyd.log <== 2019-12-11T15:53:06Z chronyd version DEVELOPMENT starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -SCFILTER -SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG) 2019-12-11T15:53:06Z Disabled control of system clock 2019-12-11T15:53:06Z Could not enable RTC interrupt : Invalid argument 2019-12-11T15:54:37Z chronyd exiting Note: ^^ this exit is me with CTRL+C after a while ==> tmp/chronyd.out <== ==> tmp/driftfile <== 0.0 1 ==> tmp/keys <== 1 MD5 abcdefghijklmnopq ==> tmp/rtcfile <== 1 1576079586 0.0 0.0 ==> tmp/tempcomp <== 0.0 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Re: [chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On 2019-12-11T16:13+0100, Christian Ehrhardt wrote: On Tue, Dec 10, 2019 at 5:59 PM Miroslav Lichvar wrote: On Tue, Dec 10, 2019 at 04:25:31PM +0100, Christian Ehrhardt wrote: > On Tue, Dec 10, 2019 at 4:19 PM Miroslav Lichvar > > I'm sorry for changing my mind, but I now think this case should be > > handled gracefully in chronyd and not avoided in the test. According > > to the man page, the -s option is supposed to work even with no RTC or > > broken RTCs. A hang or fatal error with the -s option may break > > the user's expectation. > > > > Do you agree? > > > > Yes, but I think the changes are not mutually exclusive and should both be > added. > > -s needs the change you suggested to make the fail fatal. As I tried to explain in the later post, I think chronyd -s should not fail if the RTC doesn't support interrupts, as the documentation implies chronyd can work with "broken" RTCs and we shouldn't expect the users to test it before configuring chronyd. > Otherwise users will not realize that they don't get what they ordered. There will still be the error message in the log. Can you please try the test again with the latest code? I tested with the current head being commit f5eb7daf "rtc: disable interrupts in finalization" With that the test finally worked on the two affected platforms that I had: ./run -d 103-refclock 103-refclock Testing reference clocks: non-default settings: extra_chronyd_directives= refclock SOCK /home/ubuntu/chrony/test/system/tmp/refclock.sock refclock SHM 100 starting chronyd OK waiting for synchronization OK stopping chronyd OK checking chronyd messages OK checking chronyd filesOK PASS SUMMARY: TOTAL 1 PASSED 1 FAILED 0() SKIPPED 0 () What about the 101-rtc test, Christian? ;-) signature.asc Description: PGP signature
Re: [chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On Tue, Dec 10, 2019 at 5:59 PM Miroslav Lichvar
wrote:
> On Tue, Dec 10, 2019 at 04:25:31PM +0100, Christian Ehrhardt wrote:
> > On Tue, Dec 10, 2019 at 4:19 PM Miroslav Lichvar
> > > I'm sorry for changing my mind, but I now think this case should be
> > > handled gracefully in chronyd and not avoided in the test. According
> > > to the man page, the -s option is supposed to work even with no RTC or
> > > broken RTCs. A hang or fatal error with the -s option may break
> > > the user's expectation.
> > >
> > > Do you agree?
> > >
> >
> > Yes, but I think the changes are not mutually exclusive and should both
> be
> > added.
> >
> > -s needs the change you suggested to make the fail fatal.
>
> As I tried to explain in the later post, I think chronyd -s should not
> fail if the RTC doesn't support interrupts, as the documentation
> implies chronyd can work with "broken" RTCs and we shouldn't expect
> the users to test it before configuring chronyd.
>
> > Otherwise users will not realize that they don't get what they ordered.
>
> There will still be the error message in the log.
>
> Can you please try the test again with the latest code?
>
I tested with the current head being commit f5eb7daf "rtc: disable
interrupts in finalization"
With that the test finally worked on the two affected platforms that I had:
./run -d 103-refclock
103-refclock Testing reference clocks:
non-default settings:
extra_chronyd_directives= refclock SOCK
/home/ubuntu/chrony/test/system/tmp/refclock.sock refclock SHM 100
starting chronyd OK
waiting for synchronization OK
stopping chronyd OK
checking chronyd messages OK
checking chronyd filesOK
PASS
SUMMARY:
TOTAL 1
PASSED 1
FAILED 0()
SKIPPED 0 ()
But when run in debug mode it still looks the same:
$ ./chronyd -d -s -f /root/chronyd.conf
019-12-11T14:37:35Z chronyd version DEVELOPMENT starting (+CMDMON +NTP
+REFCLOCK +RTC +PRIVDROP -SCFILTER -SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
2019-12-11T14:37:36Z System time set from RTC
2019-12-11T14:37:36Z Initial frequency -13.014 ppm
2019-12-11T14:37:36Z Could not enable RTC interrupt : Invalid argument
I'd have expected a fatal exit in these cases now - is that right?
>From reading the (new) code I'd expect RTC_Linux_Initialise to now detect
the problem and return 0 from this new section:
+ /* Make sure the RTC supports interrupts */
+ if (!switch_interrupts(0)) {
+close(fd);
+return 0;
+ }
But what I see happening is this:
gdb) b RTC_Finalise
Breakpoint 1 at 0x11bc8: file rtc.c, line 162.
(gdb) b RTC_Initialise
Breakpoint 2 at 0x119b8: file rtc.c, line 115.
(gdb) b RTC_Linux_Initialise
Breakpoint 3 at 0x373e8: file rtc_linux.c, line 509.
(gdb) b switch_interrupts
Breakpoint 4 at 0x36d28: switch_interrupts. (2 locations)
(gdb) run -d -s -f /root/chronyd.conf
Starting program: /home/ubuntu/chrony/chronyd -d -s -f /root/chronyd.conf
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/powerpc64le-linux-gnu/libthread_db.so.1".
2019-12-11T14:43:05Z chronyd version DEVELOPMENT starting (+CMDMON +NTP
+REFCLOCK +RTC +PRIVDROP -SCFILTER -SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
2019-12-11T14:43:05Z Wrong owner of /var/run/chrony (UID != 0)
2019-12-11T14:43:05Z Disabled command socket /var/run/chrony/chronyd.sock
Breakpoint 2, 0x0001000119b8 in RTC_Initialise (initial_set=1) at
rtc.c:115
115 {
(gdb) n
125 if (initial_set) {
(gdb)
126 driftfile_time = get_driftfile_time();
(gdb)
128 if (driver.time_pre_init &&
driver.time_pre_init(driftfile_time)) {
(gdb)
129 driver_preinit_ok = 1;
(gdb)
137 driver_initialised = 0;
(gdb)
141 file_name = CNF_GetRtcFile();
(gdb)
143 if (file_name) {
(gdb)
144 if (CNF_GetRtcSync()) {
(gdb)
149 if ((driver.init)()) {
(gdb)
Breakpoint 3, 0x0001000373e8 in RTC_Linux_Initialise () at
rtc_linux.c:509
509 {
(gdb)
511 fd = open(CNF_GetRtcDevice(), O_RDWR);
(gdb)
512 if (fd < 0) {
(gdb)
519 if (!switch_interrupts(0)) {
(gdb)
Breakpoint 4, 0x000100036d28 in switch_interrupts (on_off=0) at
rtc_linux.c:489
489 {
(gdb)
490 if (ioctl(fd, on_off ? RTC_UIE_ON : RTC_UIE_OFF, 0) < 0) {
(gdb)
RTC_Linux_Initialise () at rtc_linux.c:525
525 UTI_FdSetCloexec(fd);
(gdb)
527 rtc_sec = MallocArray(time_t, MAX_SAMPLES);
(gdb)
528 rtc_trim = MallocArray(double, MAX_SAMPLES);
(gdb)
529 system_times = MallocArray(struct timespec, MAX_SAMPLES);
(gdb)
532 setup_config();
(gdb)
535 coefs_file_name = CNF_GetRtcFile();
(gdb)
537 n_samples = 0;
(gdb)
538 n_samples_since_regression = 0;
(gdb)
539 n_runs = 0;
(gdb)
540 coefs_valid = 0;
(gdb)
547 SCH_AddFileHandler(fd, SCH_FILE_INPUT,
Re: [chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On Tue, Dec 10, 2019 at 04:25:31PM +0100, Christian Ehrhardt wrote: > On Tue, Dec 10, 2019 at 4:19 PM Miroslav Lichvar > > I'm sorry for changing my mind, but I now think this case should be > > handled gracefully in chronyd and not avoided in the test. According > > to the man page, the -s option is supposed to work even with no RTC or > > broken RTCs. A hang or fatal error with the -s option may break > > the user's expectation. > > > > Do you agree? > > > > Yes, but I think the changes are not mutually exclusive and should both be > added. > > -s needs the change you suggested to make the fail fatal. As I tried to explain in the later post, I think chronyd -s should not fail if the RTC doesn't support interrupts, as the documentation implies chronyd can work with "broken" RTCs and we shouldn't expect the users to test it before configuring chronyd. > Otherwise users will not realize that they don't get what they ordered. There will still be the error message in the log. Can you please try the test again with the latest code? If you would like, I think it could be improved to prepare an rtcfile and look for the "System clock off from RTC" message when hwclock doesn't report that interrupts are not supported. -- Miroslav Lichvar -- 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.
Re: [chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On Tue, Dec 10, 2019 at 4:19 PM Miroslav Lichvar wrote: > On Tue, Dec 10, 2019 at 04:11:14PM +0100, Christian Ehrhardt wrote: > > On Tue, Dec 10, 2019 at 4:06 PM Vincent Blut > wrote: > > > >+hwclock -r --test | grep -q '^ioctl.*RTC_UIE_ON.*Invalid argument$' > && > > > test_skip "RTC not RTC_UIE_ON capable" > > > > > > > > > Careful here, hwclock is internationalized. > > > > > > > Thanks for the warning, the ioctl and the flag RTC_UIE_ON should be > always > > the same. > > The errno might be changing, but we could just drop that from the check > > maybe and be safe? > > I'm sorry for changing my mind, but I now think this case should be > handled gracefully in chronyd and not avoided in the test. According > to the man page, the -s option is supposed to work even with no RTC or > broken RTCs. A hang or fatal error with the -s option may break > the user's expectation. > > Do you agree? > Yes, but I think the changes are not mutually exclusive and should both be added. -s needs the change you suggested to make the fail fatal. Otherwise users will not realize that they don't get what they ordered. But OTOH the tests should still skip if it is known to be a platform where the test won't work well. If we only add the fatal exit, then the test will not hang but will "fail" still and that is not what one would want. We know in advance that on this system it has to fail, so let's skip it. So my thought would be to apply my patch (after we fixed it up to be better - internationalization wise) AND your suggested change like: -- > Miroslav Lichvar > > > -- > 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. > > -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Re: [chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On Tue, Dec 10, 2019 at 04:11:14PM +0100, Christian Ehrhardt wrote: > On Tue, Dec 10, 2019 at 4:06 PM Vincent Blut wrote: > > >+hwclock -r --test | grep -q '^ioctl.*RTC_UIE_ON.*Invalid argument$' && > > test_skip "RTC not RTC_UIE_ON capable" > > > > > > Careful here, hwclock is internationalized. > > > > Thanks for the warning, the ioctl and the flag RTC_UIE_ON should be always > the same. > The errno might be changing, but we could just drop that from the check > maybe and be safe? I'm sorry for changing my mind, but I now think this case should be handled gracefully in chronyd and not avoided in the test. According to the man page, the -s option is supposed to work even with no RTC or broken RTCs. A hang or fatal error with the -s option may break the user's expectation. Do you agree? -- Miroslav Lichvar -- 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.
[chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On Tue, Dec 10, 2019 at 4:06 PM Vincent Blut wrote: > On 2019-12-10T15:52+0100, Christian Ehrhardt wrote: > >The test might run on different platforms. > >If the platform happens to have a RTC that does exist but unable to > >have RTC_UIE_ON set the test will fall into an infinite hang. > > > >Exampls of bad clocks are: > >- ppc64el: rtc-generic > >- arm64: rtc-efi > > > >To avoid that check the capability via `hwclock` before the test and skip > >if it is unable to use it. > > > >Signed-off-by: Christian Ehrhardt > >--- > > test/system/101-rtc | 1 + > > 1 file changed, 1 insertion(+) > > > >diff --git a/test/system/101-rtc b/test/system/101-rtc > >index fa9a70d..cbffd1c 100755 > >--- a/test/system/101-rtc > >+++ b/test/system/101-rtc > >@@ -4,6 +4,7 @@ > > > > check_chronyd_features RTC || test_skip "RTC support disabled" > > [ -c "/dev/rtc" ] || test_skip "missing /dev/rtc" > >+hwclock -r --test | grep -q '^ioctl.*RTC_UIE_ON.*Invalid argument$' && > test_skip "RTC not RTC_UIE_ON capable" > > > Careful here, hwclock is internationalized. > Thanks for the warning, the ioctl and the flag RTC_UIE_ON should be always the same. The errno might be changing, but we could just drop that from the check maybe and be safe? > > test_start "real-time clock" > -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
[chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On 2019-12-10T15:52+0100, Christian Ehrhardt wrote: The test might run on different platforms. If the platform happens to have a RTC that does exist but unable to have RTC_UIE_ON set the test will fall into an infinite hang. Exampls of bad clocks are: - ppc64el: rtc-generic - arm64: rtc-efi To avoid that check the capability via `hwclock` before the test and skip if it is unable to use it. Signed-off-by: Christian Ehrhardt --- test/system/101-rtc | 1 + 1 file changed, 1 insertion(+) diff --git a/test/system/101-rtc b/test/system/101-rtc index fa9a70d..cbffd1c 100755 --- a/test/system/101-rtc +++ b/test/system/101-rtc @@ -4,6 +4,7 @@ check_chronyd_features RTC || test_skip "RTC support disabled" [ -c "/dev/rtc" ] || test_skip "missing /dev/rtc" +hwclock -r --test | grep -q '^ioctl.*RTC_UIE_ON.*Invalid argument$' && test_skip "RTC not RTC_UIE_ON capable" Careful here, hwclock is internationalized. test_start "real-time clock" signature.asc Description: PGP signature
