[EMAIL PROTECTED] wrote:
>
> I still haven't looked at things, but two points:
> (i) is the behaviour constant on all architectures?
As it is a property of the mc146818, it should be constant across all
arch that use drivers/char/rtc.c
Sparc uses drivers/sbus/char/rtc.c which is for Mostek 480
> I don't have a problem with the rtc driver delaying 500ms
I still haven't looked at things, but two points:
(i) is the behaviour constant on all architectures?
(ii) instead of waiting, isn't it much easier to redefine
what it means to access rtc?
(If you read a certain value then on average you
[EMAIL PROTECTED] wrote:
>
> Neither hwclock nor the /dev/rtc driver takes the following comment from
> set_rtc_mmss() in arch/i386/kernel/time.c into account. As a result, using
> hwclock --systohc or --adjust always leaves the Hardware Clock 500 ms ahead of
> the System Clock:
[...]
> Sh
> Neither hwclock nor the /dev/rtc driver takes the following comment from
> set_rtc_mmss() in arch/i386/kernel/time.c into account.
> As a result, using hwclock --systohc or --adjust always leaves the
> Hardware Clock 500 ms ahead of the System Clock
By pure coincidence [EMAIL PROTECTED] sent me
On Sat, Jan 06, 2001 at 11:35:52AM -0800, [EMAIL PROTECTED] wrote:
> Neither hwclock nor the /dev/rtc driver takes the following comment from
> set_rtc_mmss() in arch/i386/kernel/time.c into account. As a result, using
> hwclock --systohc or --adjust always leaves the Hardware Clock 500 ms ah
Neither hwclock nor the /dev/rtc driver takes the following comment from
set_rtc_mmss() in arch/i386/kernel/time.c into account. As a result, using
hwclock --systohc or --adjust always leaves the Hardware Clock 500 ms ahead of
the System Clock:
* In order to set the CMOS clock precisely
6 matches
Mail list logo
