Re: [gentoo-amd64] Recent clock problems

[Mark Knecht]

On 2/11/06, Bob Slawson <bslawson@×××××××××××.net> wrote:
> Mark Knecht wrote:
> > Hello,
> >    Just in the last week or so my AMD64 machine has started to exhibit
> > problems with the clock. Maybe it's a hardware problem, or possibly
> > it's some new ntpd issue after updates. At boot time it seems to be
> > coming up with semi-random times. This is causing me to ask a few
> > questions and try to learn a bit more about how this actually works
> > under Linux. Thanks in advance.
> >
> First thing to do is to check that the symlink `/etc/localtime' still
> points to a valid timezone data file.  For instance:
>
> $ ls -l /etc/localtime
> lrwxrwxrwx 1 root root 30 Jan 21 21:52 /etc/localtime ->
> /usr/share/zoneinfo/US/Eastern
>
> works well where I live.  When I have clock problems, this symlink is
> almost always the problem.
>
>
> In /etc/conf.d/clock,  I have CLOCK="UTC", CLOCK_SYSTOHC="yes" , and
> CLOCK_OPTS="".
>
> BobS
>

Hi Bob,
   /etc/localtime seems to be OK:

mark@lightning ~ $ ls -l /etc/localtime
lrwxrwxrwx  1 root root 39 Aug 30 10:29 /etc/localtime ->
/usr/share/zoneinfo/America/Los_Angeles
mark@lightning ~ $

My clock settings seem similar, other than the UTC/local question

CLOCK="local"
CLOCK_OPTS=""
CLOCK_SYSTOHC="yes"

   Are you able to clarify about what to write into the clock when
using fist date and then hwclock? For instance yesterday I did these
commands:

date 021008002006
hwclock -w

But this morning (Feb. 11th) when I booted the clock came up saying
Feb. 9th. so I had to write it again after booting.

NOTE: The problem happens using both UTC and local so it's actually
not caused by that.

NOTE 2: I also see that system time is off by 2 minutes from what I
get from the over the phone time system. Normally they have been very
close so it seems that ntpd is not doing it's job right now either....

I suppose this could be a bad battery or something like that but this
is my newest system and is only about 6 months old so I doubt it.
Also, I had this problem for about 3 months on my old laptop when
support for that chipset came out. I'm therefore assuming it's really
a Linux problem of some type.

A bit more debug info:

lightning ~ # hwclock --debug
hwclock from util-linux-2.12r
Using /dev/rtc interface to clock.
Last drift adjustment done at 1139675735 seconds after 1969
Last calibration done at 1139675735 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
...got clock tick
Time read from Hardware Clock: 2006/02/11 10:51:26
Hw clock time : 2006/02/11 10:51:26 = 1139683886 seconds since 1969
Sat Feb 11 10:51:26 2006  -0.686794 seconds
lightning ~ #


Thanks,
Mark

-- 
gentoo-amd64@g.o mailing list