Re: hwclock issue

[Karel Zak <kzak@xxxxxxxxxx>]

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