Re: Xen 4 TSC problems

[Philippe Simonet <philippe.simonet@bluewin.ch>]

On 9/17/2011 12:40 AM, Jeremy Fitzhardinge wrote:
> On 09/15/2011 11:03 PM, Philippe.Simonet@swisscom.com wrote:
>>> -----Original Message-----
>>> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>>> bounces@lists.xensource.com] On Behalf Of Jeremy Fitzhardinge
>>> Sent: Thursday, September 15, 2011 6:25 PM
>>> To: Konrad Rzeszutek Wilk
>>> Cc: xen-devel@lists.xensource.com; 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@dnsit22.swissptt.ch ~# 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