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