|
xen-devel
RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
On Wed, 2011-06-15 at 09:11 +0100, Tian, Kevin wrote:
> > From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
> > Sent: Tuesday, June 14, 2011 4:27 AM
> >
> > One step further: the problem is that pr->pblk is not set, thus
> > acpi_processor_get_power_info_fadt fails.
> > Knowing this, I found an error in the ACPI_DEBUG output that
> > corresponds:
> >
> > [ 17.062739] processor_xen-0222 [00] xen_acpi_processor_get: Processor
> > [-1:0]
> > [ 17.062902] processor_xen-0225 [00] xen_acpi_processor_get: No PBLK
> > (NULL address)
>
> this looks a bit strange. how about the native log?
>
> >
> > It does this for all processors. pr_id is always -1, pr->acpi_id
> > counting up from 0 to 2.
>
> what's your dom0 vcpu number? and how about physical cpu?
Wasn't there some oddity in the Xen ACPI PM support due to the
disconnect between VCPU and PCPU? I thought it resulted in some CPU id
or other being reported back as -1, in much this manner.
There's some tweaking of this stuff in e.g.
xen_acpi_processor_get_power_info(). But equally
xen_acpi_processor_get_info() has a bunch of cases for the != -1 case.
Does the dom0_vcpus_pin hypervisor option workaround this sort of thing?
This changeset refers to the -1 too:
commit 68320323a51c2378aca433c76157d9e66104ff1e
Author: Jiang, Yunhong <yunhong.jiang@xxxxxxxxx>
Date: Tue Sep 14 14:41:52 2010 -0700
xen/acpi: Add cpu hotplug support
Add physical CPU hotplug support to origin/xen/next-2.6.32 branch.
Please notice that, even with this change, the acpi_processor->id is
still always -1. This is because several workaround in PM side depends
on acpi_processor->id == -1. As the CPU hotplug logic does not depends
on acpi_processor->id, I'd still keep it no changes.
But we need change the acpi_processor->id in the future.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@xxxxxxxxx>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>
Ian.
> > Any help is welcome, but I will analyze further...
>
> Current Dom0 depends on several Xen specific functions like
> xen_acpi_get_power_info
> you mentioned earlier, which is a copy from native acpi_get_power_info with
> xen
> specific tweaks added. there's possibility that in your environment general
> ACPI code
> is changed which is not reflected in Xen specific versions.
>
> Thanks
> Kevin
>
> >
> > Carsten.
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Carsten Schiers
> > Gesendet: Montag, 13. Juni 2011 15:22
> > An: ke.yu; kevin.tian
> > Cc: xen-devel
> > Betreff: AW: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
> >
> > >>I will try to boot native Linux in order to verify 100%
> > >> that the tables
> > >> are there.
> > >
> > >yes, that's interesting data to compare.
> >
> > I have booted with a Live Linux and dumped acpi tables. Those are 100%
> > identical with those
> > I received from Dom0. I will now start looking into
> > acpi_processor_get_power_info_fadt And
> > check, why it is returning -ENODEV.
> >
> > Carsten.
> >
> >
> > _______________________________________________
> > 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home