Xen project Mailing List

Thanks for the feedback Ian and Jan!

It was not a typo, we are using RHEL5/CentOS5 which started in 2007 and is not fully EOL until 2020 but the production phase ends in 2017. We do understand your point though about getting on a much newer version but unfortunately we are a small operation and that type of change in the short term for our existing systems is very cost prohibitive.

"jiffies" is the only clock source option in all our dom0s and domUs as per the following output so switching sources does not appear to be an option:
>cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>jiffies

Are you thinking that's potential sign of something off if the dom0 only has the one jiffies option? We're using the default CentOS install and have no special boot settings related to timing or the clock.

We had previously read Jan's "fix scale_delta() inline assembly" thread but based on the discussion and all related threads but we didn't think it really applied to our situation but perhaps it does. As well, our jumping appears to be much larger of a jump and way less frequent than others. We will figure out how to check if that change is included in our tree and get back to you on what we find.

The latching clock behavior seems appropriate given the situation but it seems potentially odd that the clock can then be fixed by simply issuing a "date -s" command on the domU when independent_wallclock=0. Should it not stay latched on the future date?

We shall also try the suggested RHEL bug submission path and see where that leads, thanks.

If we're stuck for the short/medium term on the latest Centos5 release with clocksource=jiffies, would switching our domU systems to independent_wallclock=1 and continuing to run ntpd have any better chance of bypassing the potential issue causing the jump or is it possible it could make things worse?

On Tue, Apr 23, 2013 at 5:33 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

On Tue, 2013-04-23 at 10:29 +0100, Jan Beulich wrote:
> >>> On 23.04.13 at 00:50, Tom W <tcte.tech@xxxxxxxxx> wrote:
> > -for all dom0s & domUs: independent_wallclock=0, ntpd is running,
> > clocksource=jiffies, Xen version 3.1.2
>
> I can only second Ian's recommendation to drop this clocksource=
> option.
>
> And unless this was a typo, you surely want to get off that really
> old hypervisor.

FWIW I had assumed this was the RHEL5/CentOS5 supplied hypervisor (it's
the right era at least) and not a typo.

> Nobody's going to help you with issues there,

If I'm right then it would be better to start by reporting a RHEL bug
IMHO.

Ian.

Re: [Xen-devel] Massive Instant Clock Jump & Freeze domU Issue (NOT Related to Drift, Live Migration or Saving/Restoring)