Forwarding this in case someone who has interest in fixing
this bug didn't notice it on LKML, or in the Debian bug
database...
Summary: when reading the hardware clock returns an error
(such as "it's not set to a valid time"), hwclock doesn't
seem to be able to set it (e.g. to a valid time). For some
foolish reason it insists on being able to read the time
before it can write it ... which is obviously bogus. (*)
The problem almost certainly came up because hwclock was
originally written around a PC/AT style RTC, which may not
even be able to return invalid times (I forget). At any
rate, that's a bad assumption in general, and this bug
deserves fixing ...
- Dave
(*) One issue is a mechanism that's specific to the PC/AT
clone RTCs: waiting for "exactly" 1/2 second after
the clock rolls over before setting the clock, since
those RTCs wait a half second. If someone has time
to work such issues: that 1/2 second delay should
(a) obviously not be attempted if the clock can't
even be read, but also (b) should not be required,
since most RTCs don't have those PC/AT semantics.
---------- Forwarded Message ----------
Subject: Re: rtc: how should I handle an invalid state?
Date: Tuesday 29 April 2008
From: Uwe Kleine-König <Uwe.Kleine-Koenig@xxxxxxxx>
To: David Brownell <david-b@xxxxxxxxxxx>
Cc: Alessandro Zummo <a.zummo@xxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx
Hi Dave,
David Brownell wrote:
> On Tuesday 29 April 2008, Uwe Kleine-König wrote:
> > The problem is that hwclock tries to read the current time before
> > setting the new one. And if that fails, it doesn't update the rtc.
>
> Which version of hwclock? That does seem like a bug in that
> particular version. If it's in util-linux-ng or busybox,
> please send in a patch. I don't think anyone should be
> deploying *new* systems using *old/unmaintained* util-linux.
This is hwclock from Debian/stable (i.e. 2.12r-19etch1). With
Debian/unstables (2.13.1-5) this happens to:
sh-3.1# /sbin/hwclock --systohc -D
hwclock from util-linux-ng 2.13.1
Using /dev interface to clock.
Last drift adjustment done at 1209474623 seconds after 1969
Last calibration done at 1209474623 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time from /dev/rtc to change
RTC_RD_TIME: Invalid argument
ioctl() to /dev/rtc to read the time failed.
Oh, there is a new version in Debian/unstable (2.14~rc1-1), nothing new
though:
sh-3.1# /sbin/hwclock --systohc -D
hwclock from util-linux-ng 2.14-rc1
Using /dev interface to clock.
Last drift adjustment done at 1209474623 seconds after 1969
Last calibration done at 1209474623 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time from /dev/rtc to change
RTC_RD_TIME: Invalid argument
ioctl() to /dev/rtc to read the time failed.
I looked a bit in the source of hwclock (from unstable) and IMHO it does
strange things. E.g. I wouldn't do
if (getuid() != 0 && systohc) {
fprintf(stderr,
_("Sorry, only the superuser can change "
"the Hardware Clock.\n"));
permitted = FALSE;
}
I wonder further why do_rtc_read_ioctl has a return type of int if it is
unchecked in read_hardware_clock_rtc which unconditionally returns 0.
(Ah, OK, do_rtc_read_ioctl always returns 0, if there is an error,
exit() is called. Nice.)
Anyhow ...
Ah, reading the hwclock is necessary to adjust /etc/adjtime. So the
correct way to set the hwclock is
# /sbin/hwclock --systohc -D --noadjfile --utc
But as you already suspect, this doesn't help either.
I'll write a bugreport to Debian as I now don't fancy to work with that
piece of code anymore. :(
> I'll suspect this is on some util-linux version, since I'm
> quite sure that I've had busybox based systems that don't
> show this misbehavior.
Right, the busybox I have here behaves fine.
> Haven't had occasion to use non-PC
> RTCs with a util-linux-ng version; I wouldn't call a bug in
> such combinations a kernel regression, either...
>
> I think the preferred solution never returns invalid times as
> valid. Some RTC drivers do this themselves:
>
> int my_rtc_read_time(struct device *dev, struct rtc_time *time)
> {
> ... read the hardware into *time ...
> return rtc_valid_tm(time);
> }
>
> Or rtc_valid_tm() might be checked in the RTC framework glue,
> to provide more uniform behavior at the framework level.
Currently it doesn't, the ioctl function for RTC_RD_TIME simply does:
err = rtc_read_time(rtc, &tm);
if (err < 0)
return err;
if (copy_to_user(uarg, &tm, sizeof(tm)))
return -EFAULT;
...
return err;
> Either way, it's not unknown that an un-initialized RTC have
> undefined state, and thus return invalid times until they've
> been set (using wall clock, NTP, or whatever).
For my rtc it's even better: There are two flags that indicate that
the clock is running and the time is valid. So I can do
if (!clock_is_running || !time_is_valid)
return -EINVAL;
else
readtime(&tm)
return 0;
I remember that the rx8025, an rtc I wrote a driver for some time ago,
had something similar.
Best regards
Uwe
--
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962
-------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
