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

On 28/1/08 21:52, "Langsdorf, Mark" <mark.langsdorf@xxxxxxx> wrote:

>> Please test with latest xen-unstable. As of changeset 16897 I
>> have fixed the vcpu affinity change, so that should actually
>> work,
> It doesn't, for some reason.  It seems to lock up on the
> v->arch.schedule_tail = continue_hypercall_on_cpu_helper
> for no reason that I can tell.  If I comment out that line,
> the system boots fine, but if that is in Xen, the machine
> softlocks shortly after starting cpufreq.  Unfortunately,
> cpufreq starts well before any console, so I can't get a
> lot of information out the system.
> I'll continue working on this, but any advance would be
> appreciated.

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.

 -- Keir

Xen-devel mailing list



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