<div><div class="gmail_quote">On Mon, Apr 25, 2011 at 12:47 PM, Denniston, Todd A CIV NAVSURFWARCENDIV Crane <span dir="ltr"><<a href="mailto:todd.denniston@navy.mil">todd.denniston@navy.mil</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:centos-bounces@centos.org">centos-bounces@centos.org</a> [mailto:<a href="mailto:centos-bounces@centos.org">centos-bounces@centos.org</a>] On<br>
</div>> Behalf Of Mailing List<br>
> Sent: Monday, April 25, 2011 13:57<br>
<div class="im">> To: CentOS mailing list<br>
> Subject: Re: [CentOS] CentOs 5.6 and Time Sync<br>
><br>
</div><div class="im">></div><div class="im">
><br>
> List,<br>
><br>
> I was not able to resolve my issue with the time on this machine.<br>
> I<br>
> went ahead and rolled the update back to 5.5 and disabled the update<br>
to<br>
> 5.6.<br>
><br>
> What I would like to know is if CentOS 6 might be ok when it rolls<br>
> out, or am I just going to have to keep with 5.5 till EOL?<br>
><br>
> Thanks to all with there help.<br>
><br>
<br>
</div>1) I hope you are only talking about having rolled back to the last<br>
working for you kernel from 5.5, not the whole distribution.<br>
<br>
2) If I was in your position and had time, my method would be[1]<br>
a) get the srpm for the last known working kernel (2.6.18-194.32 ???)<br>
b) get the srpm for the first known not working kernel (2.6.18-238 ???)<br>
c) expand each of the above srpms into their own rpm build tree<br>
i.e., rpmdev-setuptree;rpm -i kern1; mv rpmbuild rpmbuild.kern1;<br>
rpmdev-setuptree;rpm -i kern2; mv rpmbuild rpmbuild.kern2<br>
d) start looking at the differences in the patches applied in kern1 vs.<br>
those in kern2, i.e., read/diff the kernel.spec files<br>
see if there were any new ones that seemed likely to be causing the<br>
problem...<br>
RTFS if necessary to make better guesses.<br>
Rebuild kernel 2 with patches taken out/modified based on my<br>
investigations and test them and see if I guessed right.<br>
If no luck, think about opening an TUV bug with lots of the info you<br>
have sent here, they may be interested even if you don't have a<br>
subscription.<br>
<br>
[1] Been there, done that:<br>
<a href="http://www.gossamer-threads.com/lists/drbd/users/9616" target="_blank">http://www.gossamer-threads.com/lists/drbd/users/9616</a><br>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div><div>time.c: can't update CMOS clock from 59 to 0</div></div><div><div>time.c: can't update CMOS clock from 59 to 0</div></div><div><div>time.c: can't update CMOS clock from 59 to 0</div></div>
<div><div>time.c: can't update CMOS clock from 59 to 0</div></div><div><br></div><div>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.</div>
<div><br></div><div><div>[root@nexus4 ~]# date; ntpdate -u <a href="http://pool.ntp.org">pool.ntp.org</a></div><div>Mon May 9 16:51:03 PDT 2011</div><div> 9 May 16:50:21 ntpdate[22117]: step time server 207.182.243.123 offset -42.418572 sec</div>
<div><br></div><div>[root@nexus4 ~]# date; ntpdate -u <a href="http://pool.ntp.org">pool.ntp.org</a></div><div>Mon May 9 16:50:33 PDT 2011</div><div> 9 May 16:50:35 ntpdate[22127]: step time server 207.182.243.123 offset -0.692146 sec</div>
</div><div><br></div><div>Brandon</div></div></div>