On 05/09/2011 06:53 PM, Brandon Ooi wrote:
On Mon, Apr 25, 2011 at 12:47 PM, Denniston, Todd A CIV NAVSURFWARCENDIV
Crane <todd.denniston at navy.mil wrote:

-----Original Message-----
From: centos-bounces at centos.org <mailto:centos-bounces at centos.org>
[mailto: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

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
those in kern2, i.e., read/diff the kernel.spec files
see if there were any new ones that seemed likely to be causing
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
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 bug.

[root at nexus4 ~]# date; ntpdate -u pool.ntp.org <http://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 <http://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
Yes, this is obviously a problem with the kernel interacting with the
clock on some machines. IF we can figure out which ones and why, we can
get upstream to fix it.
May I ask to try upstreams current kernel first
http://people.redhat.com/jwilson/el5/ to make sure it's not already fixed

BTW: Those kernels have been very useful for me in the past and as this
example shows may also be useful for others. The sad part is that the same
doesn't apply for EL6 anymore because they don't make their dev kernels
available anymore.


Search Discussions

Discussion Posts


Related Discussions

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



site design / logo © 2022 Grokbase