Re: [Xen-devel] Xen 4 TSC problems

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

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

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