[9fans] incorrect system time

I downloaded the plan9.iso a few days ago, and when I load it up in qemu,
the system time is off by more than 6 years. However, I never had this
problem when I ran an older version of plan9 (about 3 years older). I
searched through the archive of 9fans, and there were some mention of a
similar clock drift problem on other platforms. Anyways, I checked /dev/rtc
and /dev/time. It appears that /dev/rtc is correct while /dev/time is way
off. If I do "cat /dev/rtc > /dev/time", the clock gets reset to its
correct value, but after a few minutes, it reverts back to an incorrect
value. I just wonder why I never had this problem with the older version of
plan9. If both versions show similar behavior, I would be more inclined to
put the blame on qemu.

I shall much appreciate any insight from a more experienced user of
developer of plan9.

On 11/24/06, Myron Cheung <onyx.peridot@gmail.com> wrote:[color=blue]
> I downloaded the plan9.iso a few days ago, and when I load it up in qemu,
> the system time is off by more than 6 years. However, I never had this
> problem when I ran an older version of plan9 (about 3 years older). I
> searched through the archive of 9fans, and there were some mention of a
> similar clock drift problem on other platforms. Anyways, I checked /dev/rtc
> and /dev/time. It appears that /dev/rtc is correct while /dev/time is way
> off. If I do "cat /dev/rtc > /dev/time", the clock gets reset to its
> correct value, but after a few minutes, it reverts back to an incorrect
> value.[/color]

I am still seeing the same problem. I think I fixed this in Xen by
taking the clock interrupt but always picking up the value of the time
from the rtc, but I am not sure. But there is definitely a problem
here.

ron

By the way, I also tried the most recent version of plan9.iso on a Dell PC
(celeron 2.8GHZ), the clock comes up correct.

On 11/25/06, ron minnich <rminnich@gmail.com> wrote:[color=blue]
>
> On 11/24/06, Myron Cheung <onyx.peridot@gmail.com> wrote:[color=green]
> > I downloaded the plan9.iso a few days ago, and when I load it up in[/color]
> qemu,[color=green]
> > the system time is off by more than 6 years. However, I never had this
> > problem when I ran an older version of plan9 (about 3 years older). I
> > searched through the archive of 9fans, and there were some mention of a
> > similar clock drift problem on other platforms. Anyways, I checked[/color]
> /dev/rtc[color=green]
> > and /dev/time. It appears that /dev/rtc is correct while /dev/time is[/color]
> way[color=green]
> > off. If I do "cat /dev/rtc > /dev/time", the clock gets reset to its
> > correct value, but after a few minutes, it reverts back to an incorrect
> > value.[/color]
>
> I am still seeing the same problem. I think I fixed this in Xen by
> taking the clock interrupt but always picking up the value of the time
> from the rtc, but I am not sure. But there is definitely a problem
> here.
>
> ron
>[/color]

The reason the time gets set back is that
aux/timesync is managing /dev/time. If you change
/dev/time behind its back, it will gladly "fix" it next
time it checks.

Timesync is started in termrc. It looks to me like
it should by default be syncing against /dev/rtc,
but run psu -a |grep timesync and check that it is
really running with the -r flag.

If it is, perhaps there is a bug in timesync that
needs to be found.

Russ

psu -a | grep timesync does not show the -r flag.

I killed timesync and ran it manually with the -r flag again, but psu -a
does not show the -r flag. In termrc, timesync was started with
TIMESYNCARGS=-rLa1000000 .

Myron

On 11/26/06, Russ Cox <rsc@swtch.com> wrote:[color=blue]
>
> The reason the time gets set back is that
> aux/timesync is managing /dev/time. If you change
> /dev/time behind its back, it will gladly "fix" it next
> time it checks.
>
> Timesync is started in termrc. It looks to me like
> it should by default be syncing against /dev/rtc,
> but run psu -a |grep timesync and check that it is
> really running with the -r flag.
>
> If it is, perhaps there is a bug in timesync that
> needs to be found.
>
> Russ
>[/color]

My mistake -- psu -a won't help. I forgot that timesync
forks itself into the background, and forked children don't
keep the exec arguments in the ps listing.

Russ