Hi Steve,
It's already been tested and released for SL.
It was when I was writing the errata email that I saw all the time bug 
fixes.
Troy

Steven Timm wrote:
> Troy, when will this kernel be available for SL testing?
> What they are saying is not exactly the same as what we are seeing
> but it could be worth a try.
> This is now 3 errata kernels released by the upstream vendor in
> less than a month.
> 
> Steve
> 
> 
> On Thu, 21 Jan 2010, Troy Dawson wrote:
> 
>> Steven Timm wrote:
>>> Since the errata kernel release 2.6.18-164.6.1 we have been
>>> seeing Xen domU's that will occasionally jump forward in time by
>>> 40-80 minutes.  the behavior is such that the clock will jump
>>> forward and then just sit there until the clock of the underlying
>>> dom0 catches up to it again.
>>>
>>> At first we were running ntpd on our domU's but then disabled it
>>> in response to suggestions in several howtos.  So now we know
>>> that the problem has nothing to do with rogue ntp packets but
>>> could very well be something in xen or kernel-xen that is causing it.
>>> There's a report of something very similar in the CentOS forum
>>> to which I've appended more details of this bug.
>>>
>>> https://www.centos.org/modules/newbb/viewtopic.php?topic_id=23402
>>>
>>> Nothing in the upstream vendor bugzilla about this that I can find,
>>> or nothing in the Xen mailing lists that's obvious.
>>>
>>> Any help is appreciated.
>>>
>>> Steve Timm
>>>
>>>
>> Hi Steve,
>> With the new kernel (2.6.18-164.11.1.el5) that just was released, there were 
>> lots of time bug fixes.
>>
>> http://www.redhat.com/docs/en-US/errata/RHSA-2010-0046/Kernel_Security_Update/index.html
>>
>> Here are the time related ones
>>
>> * Scientific Linux 5.4 SMP guests running on a Scientific Linux Hypervisor 
>> may have experienced inconsistent time, for example, the time going 
>> backwards. This could have caused some applications to hang.
>>
>> * In rare cases, a system management interrupt (SMI) could occur during
>> CPU frequency calibration (during boot), resulting in the frequency
>> being calculated to a value larger than the CPU's specification. This
>> could have resulted in timer values being miscalculated and firing at
>> incorrect times. Note: This fix is optional. To enable the fix, the
>> system must be booted with the avoid_smi kernel parameter.
>>
>> * A KVM pvclock fix in the kernel-2.6.18-164.2.1.el5 update introduced a
>> bug: Some SMP guest operating systems experienced time drift. This could
>> cause problems for time-sensitive applications.
>>
>> * Scientific Linux 5.4 guests using KVM pvclock, calling the
>> clock_gettime(CLOCK_REALTIME) and gettimeofday() functions in sequence
>> could have, in rare cases, caused clock_gettime() to return a smaller
>> value than gettimeofday(). If the sequence was reversed, gettimeofday()
>> could return a smaller value than clock_gettime(CLOCK_REALTIME). This
>> could cause applications to hang and use large amounts of CPU (up to
>> 100%), or cause problems for applications that depend on timestamps to
>> order events. Note: This update only resolves this issue for Intel 64
>> and AMD64 systems. The issue can still present on i386 systems.
>>
>> I am not positive that it will fix your problem, but it sure looks like this 
>> kernel they did alot of work on time and virtulization.
>>
>> Troy
>>
> 


-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LSCS/CSI/USS Group
__________________________________________________