Re: [Xen-devel] Xen 4 TSC problems

[Philippe Simonet <philippe.simonet@xxxxxxxxxx>]

On 9/17/2011 12:40 AM, Jeremy Fitzhardinge wrote:
> On 09/15/2011 11:03 PM, Philippe.Simonet@xxxxxxxxxxxx wrote:
> > > -----Original Message-----
> > > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> > > bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jeremy Fitzhardinge
> > > Sent: Thursday, September 15, 2011 6:25 PM
> > > To: Konrad Rzeszutek Wilk
> > > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Philippe Simonet
> > > Subject: Re: [Xen-devel] Xen 4 TSC problems
> > >
> > > On 09/15/2011 01:24 AM, Konrad Rzeszutek Wilk wrote:
> > > > On Tue, Sep 13, 2011 at 09:16:27AM +0200, Philippe Simonet wrote:
> > > > > Hi Xen developers
> > > > Lets try this again, this time Cc-ing Jeremy.
> > > > > i just would like to inform you that I have exactly the same problem
> > > > > with Debian squeeze and xen, with
> > > > > 50 seconds time jump on my dom0 and domu. NTP is running on all
> > > > > dom0/domuU, clocksource is 'xen'
> > > > > everywhere.
> > > > >
> > > > > some messages :
> > > > > syslog :
> > > > > Sep 11 13:56:50 dnsit22 kernel: [571603.359863] Clocksource tsc
> > > > > unstable (delta = -2999662111513 ns)
> > > > >
> > > > > xm dmesg :
> > > > > ...
> > > > > (XEN) Platform timer is 14.318MHz HPET ...
> > > > > (XEN) Platform timer appears to have unexpectedly wrapped 10 or more
> > > times.
> > > > > (XEN) TSC marked as reliable, warp = 0 (count=2) ...
> > > > >
> > > > > I had some contact with Olivier Hanesse and it indicates that he
> > > > > doesn't have any solution for this problem, and all what was proposed
> > > > > in February didn't solved this problem.
> > > That looks like Xen itself is having problems keeping track of time.  If it 
> > > can't
> > > manage it, then there's not much the guest kernels can do about it.
> > >
> > > > Which was the max_cstate=0 ?
> > > > ..
> > > > > config :
> > > > > --------------------------------------
> > > > > Linux dnsit22.swissptt.ch 2.6.32-5-xen-amd64 #1 SMP Tue Jun 14
> > > > > 12:46:30 UTC 2011 x86_64 GNU/Linux
> > > > > --------------------------------------
> > > > > HP DL385
> > > > > --------------------------------------
> > > > > vendor_id       : AuthenticAMD
> > > > > cpu family      : 16
> > > > > model           : 9
> > > > > model name      : AMD Opteron(tm) Processor 6174
> > > > > stepping        : 1
> > > > > cpu MHz         : 3058776.574
> > > > OK, that is really messed up. Your house must be on fire for the
> > > > machine to be running at 3058GHz!
> > > >
> > > > Jeremy, this sounds familiar - did we have a patch for this in your
> > > > 2.6.32 tree?
> > > Not that I can think of.  All I can suggest from the kernel side is that perhaps
> > > some of the ACPI power stuff isn't being set up properly, and that makes the
> > > CPU do very strange things with its TSC/power states in general.
> > how can i detect that ?
> >
> > the /proc/acpi/processor path is empty,
> >
> > find /proc/acpi
> >   /proc/acpi
> >   /proc/acpi/processor
> >   /proc/acpi/button
> >   /proc/acpi/button/power
> >   /proc/acpi/button/power/PWRF
> >   /proc/acpi/button/power/PWRF/info
> >   /proc/acpi/thermal_zone
> >   /proc/acpi/wakeup
> >   /proc/acpi/sleep
> >   /proc/acpi/fadt
> >   /proc/acpi/dsdt
> >   /proc/acpi/info
> >   /proc/acpi/power_resource
> >   /proc/acpi/embedded_controller
> >
> > dmesg | grep -I acpi
> >   [    1.205647] hpet_acpi_add: no address or irqs in _CRS
> >
> > lsmod | grep -i acpi
> >   acpi_processor          5087  1 processor,[permanent]
> What does "xenpm start 5" say?
>
>      J
here it is :

root@xxxxxxxxxxxxxxxxxxx ~# xenpm start 5
Timeout set to 5 seconds
Start sampling, waiting for CTRL-C or SIGINT or SIGALARM signal ...
Elapsed time (ms): 5028

CPU0:   Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU1:   Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU2:   Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU3:   Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU4:   Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU5:   Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU6:   Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU7:   Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU8:   Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU9:   Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU10:  Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU11:  Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU12:  Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU13:  Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU14:  Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU15:  Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU16:  Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU17:  Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU18:  Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU19:  Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU20:  Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU21:  Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU22:  Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz

CPU23:  Residency(ms)           Avg Res(ms)
  Avg freq      18      KHz






_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel