From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philippe Simonet Subject: Re: Xen 4 TSC problems Date: Mon, 19 Sep 2011 07:45:22 +0200 Message-ID: <4E76D6F2.5010602@bluewin.ch> References: <4E6F034B.5040102@bluewin.ch> <20110915082402.GC24888@phenom.oracle.com> <4E7226CB.2020706@goop.org> <4E73D052.3020901@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4E73D052.3020901@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: Philippe.Simonet@swisscom.com, xen-devel@lists.xensource.com, konrad.wilk@oracle.com List-Id: xen-devel@lists.xenproject.org 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