| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Xen 4 TSC problems
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
|
|
|
| |
|
Home