[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 11:20:00 +0000
  • Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 29 Jan 2008 03:20:59 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AchfqSS0Yzu1EMucEdyNUQAWy6hiGQAC1IswAA/P2j0ABsqr4AB6NDvwABlGPxsAAWGaZgABpF1v
  • Thread-topic: [Xen-devel] [PATCH] Disable Xen PowerNow! support on Opteron 2nd gen and earlier processors

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

> 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.

Changeset 16927 should fix the problem for you.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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