From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: [Xen-devel] Xen 4 TSC problems Date: Thu, 24 Feb 2011 09:43:22 -0800 (PST) Message-ID: <68c41dd8-9195-41b0-83d7-9242b8eff809@default> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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 , Olivier Hanesse , Jan Beulich Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Keir Fraser , Xen Users , Mark Adams List-Id: xen-devel@lists.xenproject.org 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 fact that a 32-bit HPET wrap is ~300 seconds and, with the "10 or more times", 10 * 300 seconds is 3000 seconds, might be a clue (or a complete red herring, but I thought it worth mentioning). Mark and Olivier, it would be interesting to know if you are using the same processor/system. > -----Original Message----- > From: Keir Fraser [mailto:keir.xen@gmail.com] > Sent: Thursday, February 24, 2011 7:52 AM > To: Olivier Hanesse; Jan Beulich > Cc: Mark Adams; Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Xen > Users; Dan Magenheimer; Keir Fraser > Subject: Re: [Xen-devel] Xen 4 TSC problems >=20 > On 24/02/2011 14:20, "Olivier Hanesse" > wrote: >=20 > > Both dom0 and domUs are affected by this" jump". > > > > I expect to see something like "TSC marked as reliable, warp =3D 0". > > I got this on newer hardware with same config/distros. >=20 > It depends on the CPU itself, older CPUs do not have the super-stable > TSC > features. But that should never cause a massive 3000s time jump. >=20 > > Is there a way to measure if it is a TSC warp ? to point out a cpu > tsc issue ? >=20 > The TSC warps or out-of-sync issues that we could reasonably expect > would be > on the order of microseconds. A 3000s warp is something else entirely. > Xen > is very confused and/or some TSC or platform timer has jumped a long > way > (indicating a hardware/firmware issue). >=20 > -- Keir >=20 > > > > 2011/2/24 Jan Beulich > >>>>> On 24.02.11 at 12:57, Olivier Hanesse > wrote: > >>> I tried to turn off cstates with max_cstate=3D0 without 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) > >> > >> This message by itself isn't telling much I believe. > >> > >>> 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_pin console=3Dvga,com1 com1=3D19200,8n1 > >>> > >>> Keir : > >>> > >>> Using clocksource=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 > >> by your DomU-s (from your past mails I wasn't actually sure whether > >> Dom0 also experienced this problem, albeit it would be odd if it > didn't). > >> > >> Jan > >> > >> Jan > >> > > > > >=20 >=20