On Mon, Apr 25, 2011 at 12:47 PM, Denniston, Todd A CIV NAVSURFWARCENDIV Crane wrote:

-----Original Message-----
From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On
Behalf Of Mailing List
Sent: Monday, April 25, 2011 13:57
To: CentOS mailing list
Subject: Re: [CentOS] CentOs 5.6 and Time Sync


I was not able to resolve my issue with the time on this machine.
went ahead and rolled the update back to 5.5 and disabled the update to

What I would like to know is if CentOS 6 might be ok when it rolls
out, or am I just going to have to keep with 5.5 till EOL?

Thanks to all with there help.
1) I hope you are only talking about having rolled back to the last
working for you kernel from 5.5, not the whole distribution.

2) If I was in your position and had time, my method would be[1]
a) get the srpm for the last known working kernel (2.6.18-194.32 ???)
b) get the srpm for the first known not working kernel (2.6.18-238 ???)
c) expand each of the above srpms into their own rpm build tree
i.e., rpmdev-setuptree;rpm -i kern1; mv rpmbuild rpmbuild.kern1;
rpmdev-setuptree;rpm -i kern2; mv rpmbuild rpmbuild.kern2
d) start looking at the differences in the patches applied in kern1 vs.
those in kern2, i.e., read/diff the kernel.spec files
see if there were any new ones that seemed likely to be causing the
RTFS if necessary to make better guesses.
Rebuild kernel 2 with patches taken out/modified based on my
investigations and test them and see if I guessed right.
If no luck, think about opening an TUV bug with lots of the info you
have sent here, they may be interested even if you don't have a

[1] Been there, done that:
At first I figured this was misconfigured NTP but I actually see this
happening on one of my machines as well. Nothing interesting about it in
particular but I verified that rolling back to the previous kernel
(2.6.18-194.32.1.el5) solves the problem entirely. This happens when NTP is
enabled or disabled. I get the following error messages in dmesg which are
possibly related.

time.c: can't update CMOS clock from 59 to 0
time.c: can't update CMOS clock from 59 to 0
time.c: can't update CMOS clock from 59 to 0
time.c: can't update CMOS clock from 59 to 0

The time drift is significantly higher than would be expected as normal.
Because rolling back the kernel completely solves this issue, this must be a

[root at nexus4 ~]# date; ntpdate -u pool.ntp.org
Mon May 9 16:51:03 PDT 2011
9 May 16:50:21 ntpdate[22117]: step time server offset
-42.418572 sec

[root at nexus4 ~]# date; ntpdate -u pool.ntp.org
Mon May 9 16:50:33 PDT 2011
9 May 16:50:35 ntpdate[22127]: step time server offset
-0.692146 sec

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.centos.org/pipermail/centos/attachments/20110509/97d99d52/attachment.html

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 35 of 37 | next ›
Discussion Overview
groupcentos @
postedApr 13, '11 at 7:35a
activeMay 12, '11 at 1:06p



site design / logo © 2022 Grokbase