Hi Ol= ivier –

&nb= sp;

It is the Xen clocksour= ce that you want to try to change, not the dom0 clocksource. To do = this, you need to specify “clocksource=3Dpit” on the Xen boot= line (and reboot), not the dom0 boot line.

I believe Mark Adams played with tsc_mode to see if it solved! =20 his (similar? identical?) problem last year, and it didn’t make any dif= ference.

Please tr= y booting Xen with “clocksource=3Dpit” and ensure that “= ;Platform timer is 1.19MHz PIT” appears in the Xen boot messages.&n= bsp; If the 50min jump does not appear again, it would point to a problem= in the hpet, either hardware or software.

Thanks,

Dan

From: Olivier Hanesse [mailto:olivier.hanesse@gmail.com]
Sen= t: Monday, February 28, 2011 7:37 AM
To: Jeremy Fitzharding= e
Cc: Dan Magenheimer; Keir Fraser; Jan Beulich; Mark Adams; xe= n-devel@lists.xensource.com; Xen Users; Keir Fraser
Subject: Re= : [Xen-devel] Xen 4 TSC problems

Hello,<= /o:p>

It happened again twice this weekend.

What about setting "tsc_mode=3D2" = for my vms ? Should this mode prevent this bug (coming from a bad emulate= d tsc due to firmware issue ? is it possible ?) from affecting time in do= mUs ?

Setting clocksource=3Dpit, make 'tsc' ava= ilable in "/sys/devices/system/clocksource/clocksource0/available_cl= ocksource" (otherwise only xen is available, is it normal ? ). =

Should I bypass xen clocksource and use tsc as= a clocksource for dom0/domU ? or will it be worsed ?

Regards

&= nbsp;

Olivier

<= o:p>

2011/2/24 Jeremy Fitzhardin= ge <jeremy@goop.org>

On 02/24/= 2011 09:43 AM, Dan Magenheimer wrote:
> Just a wild guess, but this= in Olivier's posted output:
>
> (XEN) Platform timer appears= to have unexpectedly wrapped 10 or more times.
>
> and the f= act that a 32-bit HPET wrap is ~300 seconds and, with the
> "1= 0 or more times", 10 * 300 seconds is 3000 seconds, might be a clue<= br>> (or a complete red herring, but I thought it worth mentioning).>
> Mark and Olivier, it would be interesting to know if you a= re
> using the same processor/system.

It definitely seems like some kind of problem on the host syste= m rather
than anything in the guests themselves. ! =20 If the platform timer is
misbehaving, then Xen could be completely screwi= ng up the pvclock
calibration which it then passes to guests.

C= ould it be one of those "platform clock stops in certain power state= s"
problems?

J

>> -----Original M= essage-----
>> From: Keir Fraser [mailto:keir.xen@gmail.com]
>> Sent: Thursday, Februa= ry 24, 2011 7:52 AM
>> To: Olivier Hanesse; Jan Beulich
>&= gt; Cc: Mark Adams; Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Xen
>> Users= ; Dan Magenheimer; Keir Fraser
>> Subject: Re: [Xen-devel] Xen 4= TSC problems
>>
>> On 24/02/2011 14:20, "Olivier = Hanesse" <olivier.ha= nesse@gmail.com>
>> wrote:
>>
>>> Both dom0 and domUs are affected by th= is" jump".
>>>
>>> I expect to see some= thing like "TSC marked as reliable, warp =3D 0".
>>>= ; I got this on newer hardware with same config/distros.
>> It d= epends on the CPU itself, older CPUs do not have the super-stable
>= > TSC
>> features. But that should never cause a massive 3000= s time jump.
>>
>>> Is there a way to measure if it = is a TSC warp ? to point out a cpu
>> tsc issue ?
>>>> The TSC warps or out-of-sync issues that we could reasonably ex= pect
>> would be
>> on the order of microseconds. A 300= 0s warp is something else entirely.
>> Xen
>> is very c= onfused and/or some TSC or platform timer has jumped a long
>> w= ay
>> (indicating a hardware/firmware issue).
>>
>= ;> -- Keir
>>
>>! =20 ;> 2011/2/24 Jan Beulich <JBeulich= @novell.com>
>>>>>>> On 24.02.11 at 12:57,= Olivier Hanesse <olivier= .hanesse@gmail.com>
>> wrote:
>>>>> I t= ried to turn off cstates with max_cstate=3D0 without success
>> = (still "not
>>>>> reliable").
>>>= >>
>>>>> With cpuidle=3D0, I also got :
>&g= t;>>>
>>>>> (XEN) TSC has constant rate, deep = Cstates possible, so not
>> reliable,
>>>>> wa= rp=3D3022 (count=3D1)
>>>> This message by itself isn't te= lling much I believe.
>>>>
>>>>> xm info= | grep command
>>>>> xen_commandline &nb= sp; : dom0_mem=3D512M cpuidle=3D0 loglvl=3Dall
>> guest_lo= glvl=3Dall
>>>>> dom0_max_vcpus=3D1 dom0_vcp! =20 us_pin console=3Dvga,com1 com1=3D19200,8n1
>>>>>
>>&g= t;>> Keir :
>>>>>
>>>>> Using c= locksource=3Dpit :
>>>>>
>>>>> (XEN) = Platform timer is 1.193MHz PIT
>>>>>
>>>>= ;> I also got :
>>>>>
>>>>> (XEN) = TSC has constant rate, deep Cstates possible, so not
>> reliable= ,
>>>>> warp=3D3262 (count=3D2)
>>>> The= question is whether any of this eliminates the time jumps seen
>&g= t;>> by your DomU-s (from your past mails I wasn't actually sure wh= ether
>>>> Dom0 also experienced this problem, albeit it w= ould be odd if it
>> didn't).
>>>> Jan
>>= ;>>
>>>> Jan
>>>>
>>>
= >>

--__129890608367518096abhmt020-- --===============1911446809== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users --===============1911446809==--