| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Xen 4 TSC problems
> -----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]
> J
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home