hwclock "hanging" for ~24 hours

[Tomasz Chmielewski]

I have an ARM board with isl1208 hardware clock.

When power (battery) fails, the system boots with the following kernel info:

# dmesg | grep rtc
rtc-isl1208 0-006f: chip found, driver version 0.3
rtc-isl1208 0-006f: rtc core: registered rtc-isl1208 as rtc0
rtc-isl1208 0-006f: rtc power failure detected, please set clock.


Unfortunately, "hwclock" command hangs in that case (hwclock from old util-linux, stable util-linux-ng and git tree of util-linux-ng), so booting is impossible (booting "hangs" somewhere in startup scripts when "hwclock" is executed).
It hangs so for about 24 hours (I didn't check precisely, so it may be also 10 hours, which shouldn't matter that much).

When straced, it looks like below:

# strace ./hwclock --show
execve("./hwclock", ["./hwclock", "--show"], [/* 20 vars */]) = 0
uname({sys="Linux", node="SERVER-K", ...}) = 0
brk(0) = 0x17000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=17187, ...}) = 0
mmap2(NULL, 17187, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40016000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0HO\1\0004"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1091040, ...}) = 0
mmap2(NULL, 1128068, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4001e000
mprotect(0x40125000, 50820, PROT_NONE) = 0
mmap2(0x4012c000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x106) = 0x4012c000
mmap2(0x4012f000, 9860, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4012f000
close(3) = 0
mprotect(0x4012c000, 8192, PROT_READ) = 0
mprotect(0x4001c000, 4096, PROT_READ) = 0
munmap(0x40016000, 17187) = 0
gettimeofday({184, 14828}, NULL) = 0
brk(0) = 0x17000
brk(0x38000) = 0x38000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1209120, ...}) = 0
mmap2(NULL, 1209120, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40132000
close(3) = 0
getuid32() = 0
open("/dev/rtc", O_RDONLY|O_LARGEFILE) = 3
close(3) = 0
stat64("/etc/adjtime", {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
open("/etc/adjtime", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000
read(3, "0.940732 1193442713 0.000000\n119"..., 4096) = 44
close(3) = 0
munmap(0x40016000, 4096) = 0
open("/dev/rtc", O_RDONLY|O_LARGEFILE) = 3
ioctl(3, RTC_UIE_ON, 0) = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
(...)

And it just loops here all the time.


hwclock from busybox does not have this issue and is able to read and set this clock properly (afterwards, hwclock from util-linux-ng works as well):

# ./busybox hwclock --help
(...)
Options:
-r Show hardware clock time
-s Set system time from hardware clock
-w Set hardware clock to system time
-u Hardware clock is in UTC
-l Hardware clock is in local time
-f FILE Use specified device (e.g. /dev/rtc2)


# ./busybox hwclock -r
Tue Nov 30 00:00:00 1999 0.000000 seconds
# date
Fri Aug 8 21:50:59 CEST 2008
# ./busybox hwclock -w
Fri Aug 8 21:51:24 2008 0.000000 seconds
# hwclock.disabled --show
Fri 08 Aug 2008 11:51:33 PM CEST -0.793693 seconds


See also this message on rtc-linux group:

http://groups.google.com/group/rtc-linux/browse_thread/thread/85ed7545e87bee47/e21fd0d7562fda38?lnk=gst&q=+it's+a+known+bug+of+hwclock#e21fd0d7562fda38

[Karel Zak]

Post by Tomasz Chmielewski
open("/dev/rtc", O_RDONLY|O_LARGEFILE) = 3
ioctl(3, RTC_UIE_ON, 0) = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
(...)

Yeah, our synchronize_to_clock_tick() :-)


hwclock/rtc.c, busywait_for_rtc_clock_tick():

for (i = 0;
(rc = do_rtc_read_ioctl(rtc_fd, &nowtime)) == 0
&& start_time.tm_sec == nowtime.tm_sec;
i++)
if (i >= 1000000) {
fprintf(stderr, _("Timed out waiting for time change.\n"));
return 2;
}


Karel

[Tomasz Chmielewski]

Post by Karel Zak

Post by Tomasz Chmielewski
open("/dev/rtc", O_RDONLY|O_LARGEFILE) = 3
ioctl(3, RTC_UIE_ON, 0) = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
ioctl(3, RTC_RD_TIME, {tm_sec=0, tm_min=0, tm_hour=0, tm_mday=0, tm_mon=-1, tm_year=100, ...}) = 0
(...)

Yeah, our synchronize_to_clock_tick() :-)
for (i = 0;
(rc = do_rtc_read_ioctl(rtc_fd, &nowtime)) == 0
&& start_time.tm_sec == nowtime.tm_sec;
i++)
if (i >= 1000000) {
fprintf(stderr, _("Timed out waiting for time change.\n"));
return 2;
}

What about waiting here in seconds rather than to make these loops?

i.e., wait 10 or 30 seconds, if it is more than that, bail out?


But would it solve the issue, really?

hwclock from busybox is able to show the clock (Tue Nov 30 00:00:00 1999 0.000000) and also set it; the above seems to exit only - and still, we're not able to show or set the clock?

[Karel Zak]

Post by Tomasz Chmielewski

Post by Karel Zak
Yeah, our synchronize_to_clock_tick() :-)
for (i = 0;
(rc = do_rtc_read_ioctl(rtc_fd, &nowtime)) == 0
&& start_time.tm_sec == nowtime.tm_sec;
i++)
if (i >= 1000000) {
fprintf(stderr, _("Timed out waiting for time change.\n"));
return 2;
}

What about waiting here in seconds rather than to make these loops?
i.e., wait 10 or 30 seconds, if it is more than that, bail out?

Probably yes.

Post by Tomasz Chmielewski
But would it solve the issue, really?

Yes, that's core of the problem. But we also need to remove some return
code checks from manipulate_clock(). These checks are unnecessary,
because there is hclock_valid boolean... (this is my bug.)

Post by Tomasz Chmielewski
hwclock from busybox is able to show the clock (Tue Nov 30 00:00:00
1999 0.000000) and also set it; the above seems to exit only - and
still, we're not able to show or set the clock?

I'll send a patch ASAP.

Karel

[Tomasz Chmielewski]

Karel Zak schrieb:

(...)

Post by Karel Zak

Post by Tomasz Chmielewski
But would it solve the issue, really?

Yes, that's core of the problem. But we also need to remove some return
code checks from manipulate_clock(). These checks are unnecessary,
because there is hclock_valid boolean... (this is my bug.)

Post by Tomasz Chmielewski
hwclock from busybox is able to show the clock (Tue Nov 30 00:00:00
1999 0.000000) and also set it; the above seems to exit only - and
still, we're not able to show or set the clock?

I'll send a patch ASAP.

Could you notify the list when the patch is ready, please?

[Karel Zak]

Post by Tomasz Chmielewski
(...)

Post by Karel Zak

Post by Tomasz Chmielewski
But would it solve the issue, really?

Yes, that's core of the problem. But we also need to remove some return
code checks from manipulate_clock(). These checks are unnecessary,
because there is hclock_valid boolean... (this is my bug.)

Post by Tomasz Chmielewski
hwclock from busybox is able to show the clock (Tue Nov 30 00:00:00
1999 0.000000) and also set it; the above seems to exit only - and
still, we're not able to show or set the clock?

I'll send a patch ASAP.

Could you notify the list when the patch is ready, please?

The patch is below. It's based on gettimeofday() rather than on
SIGALRM (alarm(2)). The gettimeofday has some overhead, but it
shouldn't be a big problem for the synchronization function (... and
it's fallback for systems without RTC_UIE_ON).

Please, test & review. I'd like to use the patch in 2.14.1.

Karel

--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Karel Zak]

Post by Karel Zak

Post by Tomasz Chmielewski
(...)

Post by Karel Zak

Post by Tomasz Chmielewski
But would it solve the issue, really?

Yes, that's core of the problem. But we also need to remove some return
code checks from manipulate_clock(). These checks are unnecessary,
because there is hclock_valid boolean... (this is my bug.)

Post by Tomasz Chmielewski
hwclock from busybox is able to show the clock (Tue Nov 30 00:00:00
1999 0.000000) and also set it; the above seems to exit only - and
still, we're not able to show or set the clock?

I'll send a patch ASAP.

Could you notify the list when the patch is ready, please?

The patch is below. It's based on gettimeofday() rather than on
SIGALRM (alarm(2)). The gettimeofday has some overhead, but it
shouldn't be a big problem for the synchronization function (... and
it's fallback for systems without RTC_UIE_ON).
Please, test & review. I'd like to use the patch in 2.14.1.
From 50506d3535f4af36a550dcd91136224a608e61f7 Mon Sep 17 00:00:00 2001

From: Karel Zak <kzak-H+wXaHxf7aLQT0dZR+***@public.gmane.org>
Date: Tue, 12 Aug 2008 13:58:51 +0200
Subject: [PATCH] hwclock: use time limit for synchronization busy wait

Signed-off-by: Karel Zak <kzak-H+wXaHxf7aLQT0dZR+***@public.gmane.org>
---
hwclock/clock.h | 1 +
hwclock/hwclock.c | 2 +-
hwclock/rtc.c | 23 ++++++++++++-----------
3 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/hwclock/clock.h b/hwclock/clock.h
index 6e8a9b4..cbdf999 100644
--- a/hwclock/clock.h
+++ b/hwclock/clock.h
@@ -33,6 +33,7 @@ extern void outsyserr(char *msg, ...)
#else
;
#endif
+extern double time_diff(struct timeval subtrahend, struct timeval subtractor);
/* cmos.c */
extern void set_cmos_epoch(int ARCconsole, int SRM);
extern void set_cmos_access(int Jensen, int funky_toy);
diff --git a/hwclock/hwclock.c b/hwclock/hwclock.c
index 12e7676..44f648c 100644
--- a/hwclock/hwclock.c
+++ b/hwclock/hwclock.c
@@ -182,7 +182,7 @@ read_date_from_file (struct tm *tm) {
write_date_to_file (tm);
}

-static double
+double
time_diff(struct timeval subtrahend, struct timeval subtractor) {
/*---------------------------------------------------------------------------
The difference in seconds between two times in "timeval" format.
diff --git a/hwclock/rtc.c b/hwclock/rtc.c
index 3eb1f4e..e59414f 100644
--- a/hwclock/rtc.c
+++ b/hwclock/rtc.c
@@ -179,8 +179,8 @@ busywait_for_rtc_clock_tick(const int rtc_fd) {
struct tm start_time;
/* The time when we were called (and started waiting) */
struct tm nowtime;
- int i; /* local loop index */
int rc;
+ struct timeval begin, now;

if (debug)
printf(_("Waiting in loop for time from %s to change\n"),
@@ -191,25 +191,26 @@ busywait_for_rtc_clock_tick(const int rtc_fd) {
return 1;

/* Wait for change. Should be within a second, but in case something
- weird happens, we have a limit on this loop to reduce the impact
- of this failure.
- */
- for (i = 0;
- (rc = do_rtc_read_ioctl(rtc_fd, &nowtime)) == 0
- && start_time.tm_sec == nowtime.tm_sec;
- i++)
- if (i >= 1000000) {
+ * weird happens, we have a time limit (1.5s) on this loop to reduce the
+ * impact of this failure.
+ */
+ gettimeofday(&begin, NULL);
+ do {
+ rc = do_rtc_read_ioctl(rtc_fd, &nowtime);
+ if (rc || start_time.tm_sec != nowtime.tm_sec)
+ break;
+ gettimeofday(&now, NULL);
+ if (time_diff(now, begin) > 1.5) {
fprintf(stderr, _("Timed out waiting for time change.\n"));
return 2;
}
+ } while(1);

if (rc)
return 3;
return 0;
}

-

[Tomasz Chmielewski]

Karel Zak schrieb:

(...)

Post by Karel Zak
The patch is below. It's based on gettimeofday() rather than on
SIGALRM (alarm(2)). The gettimeofday has some overhead, but it
shouldn't be a big problem for the synchronization function (... and
it's fallback for systems without RTC_UIE_ON).
Please, test & review. I'd like to use the patch in 2.14.1.

It does not "hang" anymore:

# ./hwclock --show
Timed out waiting for time change.


But still, it won't set the hardware clock so it can start ticking:

# date
Tue Aug 12 13:13:59 UTC 2008
# ./hwclock --systohc
Timed out waiting for time change.

[Karel Zak]

Post by Tomasz Chmielewski
(...)

Post by Karel Zak
The patch is below. It's based on gettimeofday() rather than on
SIGALRM (alarm(2)). The gettimeofday has some overhead, but it
shouldn't be a big problem for the synchronization function (... and
it's fallback for systems without RTC_UIE_ON).
Please, test & review. I'd like to use the patch in 2.14.1.

# ./hwclock --show
Timed out waiting for time change.

Cool.

Post by Tomasz Chmielewski
# date
Tue Aug 12 13:13:59 UTC 2008
# ./hwclock --systohc
Timed out waiting for time change.

Yes, I know. See below. Sorry, I hope you have all my patches now.

Karel

Post by Tomasz Chmielewski
From 5bd30176f33fb03632c5381826fde92b9094dcf4 Mon Sep 17 00:00:00 2001

From: Karel Zak <kzak-H+wXaHxf7aLQT0dZR+***@public.gmane.org>
Date: Sat, 9 Aug 2008 01:22:08 +0200
Subject: [PATCH] hwclock: clean up return codes

* don't check synchronize_to_clock_tick() return code.
It seem that

rtc-isl1208 0-006f: chip found, driver version 0.3
rtc-isl1208 0-006f: rtc core: registered rtc-isl1208 as rtc0
rtc-isl1208 0-006f: rtc power failure detected, please set clock.

causes that hardware clock returns persistent time and synchronization
is impossible. The hwclock(8) has to ignore this problem and allows to
set clock anyway.

* read_hardware_clock_rtc() should to return proper code (-1) in case
of ioctl failure.

* synchronize_to_clock_tick() shouldn't to print the "...got clock tick"
debug message in case of failure.

Signed-off-by: Karel Zak <kzak-H+wXaHxf7aLQT0dZR+***@public.gmane.org>
---
hwclock/hwclock.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/hwclock/hwclock.c b/hwclock/hwclock.c
index 12e7676..0b30a90 100644
--- a/hwclock/hwclock.c
+++ b/hwclock/hwclock.c
@@ -352,7 +352,12 @@ synchronize_to_clock_tick(void) {

rc = ur->synchronize_to_clock_tick();

- if (debug) printf(_("...got clock tick\n"));
+ if (debug) {
+ if (rc)
+ printf(_("...synchronization failed\n"));
+ else
+ printf(_("...got clock tick\n"));
+ }

return rc;
}
@@ -1092,9 +1097,7 @@ manipulate_clock(const bool show, const bool adjust, const bool noadjfile,

if (show || adjust || hctosys || !noadjfile) {
/* data from HW-clock are required */
- rc = synchronize_to_clock_tick();
- if (rc)
- return EX_IOERR;
+ synchronize_to_clock_tick();
gettimeofday(&read_time, NULL);
rc = read_hardware_clock(universal, &hclock_valid, &hclocktime);
if (rc)

[Tomasz Chmielewski]

Karel Zak schrieb:

(...)

Post by Karel Zak

Post by Tomasz Chmielewski
# date
Tue Aug 12 13:13:59 UTC 2008
# ./hwclock --systohc
Timed out waiting for time change.

Yes, I know. See below. Sorry, I hope you have all my patches now.

Looks like all is set - thanks!

# ./hwclock --show
Timed out waiting for time change.
Tue Nov 30 00:00:00 1999 -1.520102 seconds
# ./hwclock --show
Timed out waiting for time change.
Tue Nov 30 00:00:00 1999 -1.509624 seconds
# ./hwclock --systohc
Timed out waiting for time change.
# ./hwclock --show
Tue Aug 12 14:13:47 2008 -0.469137 seconds
# ./hwclock --systohc
#

[Alain Guibert]

Hello Karel,

Post by Karel Zak
The patch is below. It's based on gettimeofday() rather than on
SIGALRM (alarm(2)). The gettimeofday has some overhead, but it
shouldn't be a big problem

Both patches fix Tomasz hang, so they are good.

Indeed, the gettimeofday() and related manipulations seem to have a
small overhead, around 5% of the total time in loop. The big part is
ioctl(RTC_RD_TIME) which is a heavy operation. On my slow test machine,
the RTC_RD_TIME alone takes 57 =B5s, the rest of the loop takes 3 =B5s,=
and
the time wasted after the loop adds 35 =B5s.

So, on one side 5% is not much. OTOS using alarm() for timeout,
a sharper loop, and an immediate timestamping of the detected tick, the
equivalent busywait_second_change() function in adjtimex 1.26 takes
57 =B5s total. No overhead, neither in loop nor after.


BTW busywait_for_rtc_clock_tick() is called only when RTC_UIE_ON fails.
What about also calling it when RTC_UIE_ON succeeds, but waiting for th=
e
interrupt timeouts? This is unfortunately a quite common case these
days, with all those misconfigured HPETs. Affected people would then ge=
t
normal tick synchronization.


Alain.
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng=
" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html