[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Disable Xen PowerNow! support on Opteron 2nd gen and earlier processors

  • To: "Langsdorf, Mark" <mark.langsdorf@xxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Tue, 29 Jan 2008 10:32:59 +0000
  • Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 29 Jan 2008 02:35:23 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AchfqSS0Yzu1EMucEdyNUQAWy6hiGQAC1IswAA/P2j0ABsqr4AB6NDvwABlGPxsAAWGaZg==
  • Thread-topic: [Xen-devel] [PATCH] Disable Xen PowerNow! support on Opteron 2nd gen and earlier processors

On 29/1/08 09:53, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> wrote:

> As promised I've instrumented and kicked that code path, and I execute it
> with no problems, with the VCPU concerned being correctly migrated before
> and after the continue_hypercall_on_cpu() is executed. I've tried it with
> 'dom0_vcpus_pin' and also I've tried making fairly extreme calls to
> cpu_frequency_change() inside the hypercall-continuation 'helper' function.
> None of this causes my dom0 boot to hang. So it looks like something a bit
> subtle must be going wrong on your test system.

Actually I've now eyeballed the problem. We access a stack variable after
the stack frame is gone away. Probably we therefore end up setting a CPU's
frequency to zero, which is not good at all. I'll work up a fix.

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.