On Wed, Apr 30, 2008 at 12:50:50AM -0700, David Brownell wrote:
> 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
I think we have two issues here.
1) hwclock(8) always reads the hardware clock, although, for example:
hwclock --systohc --noadjfile --utc
needn't any data from the hardware clock. This problem has been
reported by Uwe.
> (*) 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
2) IMHO this is a separate issue.
> 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.
ad (b) - is there any way how to differ between "modern" RTCs and
PC/AT style RTC?
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
--
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
