[7562] in testers
clock problem on IBM ThinkCentre S50?
daemon@ATHENA.MIT.EDU (Robert A Basch)
Sun Aug 20 13:46:51 2006
Message-Id: <200608201746.k7KHkWxP014743@abulia.mit.edu>
To: testers@MIT.EDU
Date: Sun, 20 Aug 2006 13:46:32 -0400
From: Robert A Basch <rbasch@MIT.EDU>
The other day I noticed that the system clock on anhedonia.mit.edu,
my IBM ThinkCentre S50 (2.8GHz), was running very slowly, making the
system almost unusable; the system time was running many hours behind.
The only pertinent thing I noticed in /var/log/messages was a
"synchronisation lost" diagnostic from ntpd, about a minute or so
after startup. Initially I figured this was caused by a hardware
problem (the machine has been sounding rather sickly lately), but,
after realizing that the onset of the problem seemed to correlate with
the update to 9.4.29, and that this update included a new kernel, last
night I decided to revert the kernel and see if the problem still
occurred. Well, since rebooting with the old kernel around 7:30 PM
Saturday, the system clock seems fine, although ntpd still logged a
"synchronisation lost" diagnostic shortly after startup.
Using athinfo and hostinfo, I then tried to find another ThinkCentre
S50 running 9.4.29, and found that space-invaders' clock is running
about 36 hours behind:
abulia> athinfo space-invaders date ; sleep 60 ; athinfo space-invaders date
Sat Aug 19 01:17:17 EDT 2006
Sat Aug 19 01:17:25 EDT 2006
abulia> athinfo space-invaders version | tail -1
Athena Workstation (linux) Version 9.4.29 Tue Aug 15 01:26:46 EDT 2006
I will try updating the kernel again on my machine today to see if
the problem reoccurs.
Does anyone else have a ThinkCentre S50 running 9.4.29, to provide
another data point? (My other Linux machine, an HP, is doing fine
with 9.4.29).
To try the older kernel, I installed the following RPMs, using rpm's
"--oldpackage" option:
kernel-2.6.9-34.0.2.EL
kernel-devel-2.6.9-34.0.2.EL
kernel-utils-2.4-13.1.80
and updated /boot/grub/grub.conf accordingly.
Incidentally, the machine's hardware clock (displayed by "hwclock -r")
was actually running slightly ahead, so I don't think it is part of
the problem here.
Bob
