From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier Hanesse Subject: Re: [Xen-devel] Xen 4 TSC problems Date: Thu, 24 Feb 2011 12:57:15 +0100 Message-ID: References: <4D6648220200007800033769@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1556827642==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com To: Keir Fraser Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Dan Magenheimer , Jan Beulich , Xen Users , Mark Adams List-Id: xen-devel@lists.xenproject.org --===============1556827642== Content-Type: multipart/alternative; boundary=0016e64caa7e21f5f6049d05ea9e --0016e64caa7e21f5f6049d05ea9e Content-Type: text/plain; charset=ISO-8859-1 Jan : I tried to turn off cstates with max_cstate=0 without success (still "not reliable"). With cpuidle=0, I also got : (XEN) TSC has constant rate, deep Cstates possible, so not reliable, warp=3022 (count=1) xm info | grep command xen_commandline : dom0_mem=512M cpuidle=0 loglvl=all guest_loglvl=all dom0_max_vcpus=1 dom0_vcpus_pin console=vga,com1 com1=19200,8n1 Keir : Using clocksource=pit : (XEN) Platform timer is 1.193MHz PIT I also got : (XEN) TSC has constant rate, deep Cstates possible, so not reliable, warp=3262 (count=2) 2011/2/24 Keir Fraser > On 24/02/2011 10:59, "Jan Beulich" wrote: > > >>>> On 24.02.11 at 10:59, Olivier Hanesse > wrote: > >> (XEN) Platform timer appears to have unexpectedly wrapped 10 or more > times. > >> > >> Output of xm debug-key s : > >> > >> (XEN) TSC has constant rate, deep Cstates possible, so not reliable, > >> warp=2684 (count=4) > > > > Did you try turning of use of C states ("cpuidle=0" on the Xen > > command line)? > > Another thing to try is changing the platform timer that Xen uses. It's > using HPET on your machines, so try clocksource=pit on Xen command line, > and > confirm that the 'Platform timer is xxx' message changes in xm dmesg. > > However, this bug looks more like a CPU's TSC jumping forward (or maybe > backward) for some inexplicable reason. We added code post 3.2 to detect > the > platform timer counter wrapping, and to account for that based on trusting > the CPU's 64-bit TSC. But if the TSC value is bogus then we can detect a > wrap when it didn't happen and the new code will do more harm than good. It > is not currently possible to disable the code via a boto parameter -- maybe > we could add that. However, if the problem is a jumpy TSC then it is better > to fix that as Xen relies so heavily on TSC for time handling. > > -- Keir > > > Jan > > > > > --0016e64caa7e21f5f6049d05ea9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jan :=A0

I tried to turn off cstates with max_cstate= =3D0=A0without success (still "not reliable").

With cpuidle=3D0, I also got :

(XEN) TSC has constant rate, deep Cstates possible, so = not reliable, warp=3D3022 (count=3D1)

xm info= | grep command
xen_commandline =A0 =A0 =A0 =A0: dom0_mem=3D512M = cpuidle=3D0 loglvl=3Dall guest_loglvl=3Dall dom0_max_vcpus=3D1 dom0_vcpus_p= in console=3Dvga,com1 com1=3D19200,8n1

Keir :=A0

Using clocksou= rce=3Dpit :

(XEN) Platform timer is 1.19= 3MHz PIT

I also got : =A0

(XEN) TSC has constant rate, deep Cstates possible, so not reliable, warp= =3D3262 (count=3D2)

2011/2/24 Keir Fraser <keir@xen.org>
On 24/02/= 2011 10:59, "Jan Beulich" <JBeulich@novell.com> wrote:

>>>> On 24.02.11 at 10:59, Olivier Hanesse <olivier.hanesse@gmail.com> wrote:
>> (XEN) Platform timer appears to have unexpectedly wrapped 10 or mo= re times.
>>
>> Output of xm debug-key s :
>>
>> (XEN) TSC has constant rate, deep Cstates possible, so not reliabl= e,
>> warp=3D2684 (count=3D4)
>
> Did you try turning of use of C states ("cpuidle=3D0" on the= Xen
> command line)?

Another thing to try is changing the platform timer that Xen us= es. It's
using HPET on your machines, so try clocksource=3Dpit on Xen command line, = and
confirm that the 'Platform timer is xxx' message changes in xm dmes= g.

However, this bug looks more like a CPU's TSC jumping forward (or maybe=
backward) for some inexplicable reason. We added code post 3.2 to detect th= e
platform timer counter wrapping, and to account for that based on trusting<= br> the CPU's 64-bit TSC. But if the TSC value is bogus then we can detect = a
wrap when it didn't happen and the new code will do more harm than good= . It
is not currently possible to disable the code via a boto parameter -- maybe=
we could add that. However, if the problem is a jumpy TSC then it is better=
to fix that as Xen relies so heavily on TSC for time handling.

=A0-- Keir

> Jan
>



--0016e64caa7e21f5f6049d05ea9e-- --===============1556827642== 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 --===============1556827642==--