AW: RE: RE: RE: RE: RE: No C-States any longer...

AW: RE: RE: RE: RE: RE: No C-States any longer...

[Carsten Schiers]

Thanks for your support. 

So the plan is to run the very kernel (2.6.32.40 from Jeremy's git) natively, without Xen, and check 
what acpi.debug and my printks are reporting?

Would the other check be to change pr_id from -1 to 0 by some helper code in the right place?

Have I correctly understood that my BIOS seems to implement C-States through FADT instead of _CST, 
which is ok generally, but the FADT PBLK is not correctly set (maybe because it worries about the -1)?

By the way: 

  - I dom0_vcpus_pin and restrict Dom0 to only use one vcpu in xend-config.sxp
  - I used Xen/Debian Squeeze PVOPS Xen Kernel on the Intel Box
  - The same combo fails on the AMD box, latest PVOPS, too. Further testing done with latest PVOPS.

Everything used to work with Xen / 2.6.18 Dom0 Kernel, but I cannot check that, because it will not 
boot any longer, because it doesn't find the root system. I currently concentrate on the C-State 
issue.

Carsten.


----- Originalnachricht -----
Von: "Tian, Kevin" <kevin.tian@intel.com>
Gesendet: Mit, 15.6.2011 10:39
An: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Carsten Schiers <carsten@schiers.de> ; "Yu, Ke" <ke.yu@intel.com> ; xen-devel <xen-devel@lists.xensource.com>
Betreff: RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Wednesday, June 15, 2011 4:35 PM
> 
> On Wed, 2011-06-15 at 09:11 +0100, Tian, Kevin wrote:
> > > From: Carsten Schiers [mailto:carsten@schiers.de]
> > > 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.

yes, the existing tricky changes are mostly used to tackle this disconnection.

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

We don't want to add that limitation to have dom0 vcpu number same as 
physical cpu number to use PM features. But yes Carsten can try use
same number to see whether it works for him. If it works, then there's other
corner cases we didn't capture. But since this works on his Intel box, which
I guess same configuration is used, I'd think it may come from some oddity
in AMD box's ACPI table which is not well handled by either common ACPI
code or Xen specific stubs.

Thanks
Kevin

> 
> This changeset refers to the -1 too:
> 
> commit 68320323a51c2378aca433c76157d9e66104ff1e
> Author: Jiang, Yunhong <yunhong.jiang@intel.com>
> 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@intel.com>
>     Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> 
> 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@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> > >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

Re: RE: RE: RE: RE: RE: No C-States any longer...

[Konrad Rzeszutek Wilk]

On Wed, Jun 15, 2011 at 11:03:58AM +0200, Carsten Schiers wrote:
> Thanks for your support. 
> 
> So the plan is to run the very kernel (2.6.32.40 from Jeremy's git) natively, without Xen, and check 
> what acpi.debug and my printks are reporting?
> 
> Would the other check be to change pr_id from -1 to 0 by some helper code in the right place?
> 
> Have I correctly understood that my BIOS seems to implement C-States through FADT instead of _CST, 
> which is ok generally, but the FADT PBLK is not correctly set (maybe because it worries about the -1)?

So the FADT PBLK is about this line:
            Processor (CP00, 0x10, 0x00000410, 0x06)

in your DSDT. The 0x0000410 is the PBLK and somehow it is NULL on your box. You could
run iasl -d on the DSDT to find out what exactly is there.

But I *think* that should not affect the C-states as it is just used for reserving some
CardBus regions.

> 
> By the way: 
> 
>   - I dom0_vcpus_pin and restrict Dom0 to only use one vcpu in xend-config.sxp
>   - I used Xen/Debian Squeeze PVOPS Xen Kernel on the Intel Box
>   - The same combo fails on the AMD box, latest PVOPS, too. Further testing done with latest PVOPS.

So just so that you don't lose heart - the C states do work on my AMD box.

Interstingly the _PSS states are being reported as non-existent - but on baremetal
they seem to exist.

AW: RE: RE: RE: RE: RE: No C-States any longer...

[Carsten Schiers]

>So just so that you don't lose heart - the C states do work on my AMD box.
>
>Interstingly the _PSS states are being reported as non-existent - but on baremetal
>they seem to exist.

Very intersting, as P-States work perfectly with my AMD box...

Cheers,
Carsten.

Re: RE: RE: RE: RE: RE: No C-States any longer...

[Konrad Rzeszutek Wilk]

On Wed, Jun 15, 2011 at 09:06:38AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jun 15, 2011 at 11:03:58AM +0200, Carsten Schiers wrote:
> > Thanks for your support. 
> > 
> > So the plan is to run the very kernel (2.6.32.40 from Jeremy's git) natively, without Xen, and check 
> > what acpi.debug and my printks are reporting?
> > 
> > Would the other check be to change pr_id from -1 to 0 by some helper code in the right place?
> > 
> > Have I correctly understood that my BIOS seems to implement C-States through FADT instead of _CST, 
> > which is ok generally, but the FADT PBLK is not correctly set (maybe because it worries about the -1)?
> 
> So the FADT PBLK is about this line:
>             Processor (CP00, 0x10, 0x00000410, 0x06)
> 
> in your DSDT. The 0x0000410 is the PBLK and somehow it is NULL on your box. You could
> run iasl -d on the DSDT to find out what exactly is there.
> 
> But I *think* that should not affect the C-states as it is just used for reserving some
> CardBus regions.

Or maybe not:http://www.coreboot.org/ACPI

AW: Re: RE: RE: RE: RE: RE: No C-States any longer...

[Carsten Schiers]

>> But I *think* that should not affect the C-states as it is just used 
for reserving some
>> CardBus regions.
>
>Or maybe not:http://www.coreboot.org/ACPI

That's where I got my information from. So wither we have a problem in 
accessing the tables 
(very unprobable ) or the logic has changed between 2.6.18.8 and 
2.6.32-pvops what happens
If a BIOS doesn't provide C-State information at all...

Carsten. 

RE: RE: RE: RE: RE: RE: No C-States any longer...

[Tian, Kevin]

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Wednesday, June 15, 2011 9:07 PM
> 
> On Wed, Jun 15, 2011 at 11:03:58AM +0200, Carsten Schiers wrote:
> > Thanks for your support.
> >
> > So the plan is to run the very kernel (2.6.32.40 from Jeremy's git) natively,
> without Xen, and check
> > what acpi.debug and my printks are reporting?
> >
> > Would the other check be to change pr_id from -1 to 0 by some helper code in
> the right place?
> >
> > Have I correctly understood that my BIOS seems to implement C-States
> through FADT instead of _CST,
> > which is ok generally, but the FADT PBLK is not correctly set (maybe because
> it worries about the -1)?
> 
> So the FADT PBLK is about this line:
>             Processor (CP00, 0x10, 0x00000410, 0x06)
> 
> in your DSDT. The 0x0000410 is the PBLK and somehow it is NULL on your box.
> You could
> run iasl -d on the DSDT to find out what exactly is there.

Just a caveat that manual iasl may not match the actual content observed by the
kernel, because OSPM may notify BIOS for its supported capability which then
may further impact final visible content. :-)

Thanks
Kevin

RE: RE: RE: RE: RE: RE: No C-States any longer...

[Tian, Kevin]

> From: Carsten Schiers [mailto:carsten@schiers.de]
> Sent: Wednesday, June 15, 2011 5:04 PM
> 
> Thanks for your support.
> 
> So the plan is to run the very kernel (2.6.32.40 from Jeremy's git) natively,
> without Xen, and check
> what acpi.debug and my printks are reporting?

yes

> 
> Would the other check be to change pr_id from -1 to 0 by some helper code in
> the right place?

In the native case pr->id can be -1 only under CPU hotplug case, or else it
should be a valid number in all cases. In Xen due to the difference between
dom0's VCPU and underlying PCPU, the extra logic is added to retrieve
ACPI object even when pr->id is -1.

> 
> Have I correctly understood that my BIOS seems to implement C-States
> through FADT instead of _CST,
> which is ok generally, but the FADT PBLK is not correctly set (maybe because it
> worries about the -1)?

I checked ACPI spec again. PBLK is an optional processor control block though it's
generally implemented in most platforms. It includes system I/O port address which
can be used to throttle CPU clock or enter C2/C3 in a static manner. When the
BIOS provides _CST methods which is a more flexible and preferred way to carry
Cstate information, PBLK is not used. Or else PBLK provides basic information to
control C-state, and FADT table contains latency info about C2/C3

So if your platform BIOS reports ACPI table correctly, I would expect:
- either there's a valid _CST existing
- or there's a valid PBLK info which is accompanied with valid Cstate info in FADT 

In your case there's no _CST found, and then no PBLK found. So the code simply
early returns w/o further acquiring FADT info:

static int acpi_processor_get_power_info_fadt(struct acpi_processor *pr)
{

        if (!pr)
                return -EINVAL;

        if (!pr->pblk)
                return -ENODEV;

> 
> By the way:
> 
>   - I dom0_vcpus_pin and restrict Dom0 to only use one vcpu in
> xend-config.sxp

So you can try use same VCPU number as physical number, to see whether this
issue is caused by the mismatch.

>   - I used Xen/Debian Squeeze PVOPS Xen Kernel on the Intel Box
>   - The same combo fails on the AMD box, latest PVOPS, too. Further testing
> done with latest PVOPS.

do you mean the latest PVOPS from Konzad? I don't think Cstate/Pstate patches
have been carried there, which still stay in Jeremy's tree.

Since this is the AMD box which I'm not familiar with, also CC Mark here who is
the owner for power management on AMD boxes.

> 
> Everything used to work with Xen / 2.6.18 Dom0 Kernel, but I cannot check that,
> because it will not
> boot any longer, because it doesn't find the root system. I currently
> concentrate on the C-State
> issue.
> 

Thanks
Kevin

Re: RE: RE: RE: RE: RE: No C-States any longer...

[Konrad Rzeszutek Wilk]

> >   - The same combo fails on the AMD box, latest PVOPS, too. Further testing
> > done with latest PVOPS.
> 
> do you mean the latest PVOPS from Konzad? I don't think Cstate/Pstate patches
> have been carried there, which still stay in Jeremy's tree.

I stuck them in the stable/2.6.39.x tree. They they do need some refactoring
for them be upstreamable.

AW: RE: RE: RE: RE: RE: RE: No C-States any longer...

[Carsten Schiers]

[-- Attachment #1.1: Type: text/plain, Size: 3020 bytes --]

>> So the plan is to run the very kernel (2.6.32.40 from Jeremy's git)
natively,

>> without Xen, and check

>> what acpi.debug and my printks are reporting?

> 

>yes

 

Booting the very kernel on bare hardware will not change the way things
are running, 

despite one small change: the CPUs are registered as "cooling devices"
?!?

 

[    3.568766] ACPI: Power Button [PWRF]

[    3.734140] acpi_processor_get_power_info called

[    3.734200] acpi_processor_get_power_info zeroes all c-states

[    3.734260] acpi_processor_get_power_info analyzes cst

[    3.734319] acpi_processor_get_power_info_cst called

[    3.734377] acpi_processor_get_power_info_cst conted

[    3.734436] acpi_processor_get_power_info_cst bad cst

[    3.734495] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.734556] acpi_processor_get_power_info analyzes fadt

[    3.734614] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.734675] acpi_processor_get_power_info we have a result

[    3.734774] processor LNXCPU:00: registered as cooling_device0

[    3.734855] acpi_processor_get_power_info called

[    3.734912] acpi_processor_get_power_info zeroes all c-states

[    3.734973] acpi_processor_get_power_info analyzes cst

[    3.735031] acpi_processor_get_power_info_cst called

[    3.735089] acpi_processor_get_power_info_cst conted

[    3.735147] acpi_processor_get_power_info_cst bad cst

[    3.735206] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.735267] acpi_processor_get_power_info analyzes fadt

[    3.735325] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.735386] acpi_processor_get_power_info we have a result

[    3.735463] processor LNXCPU:01: registered as cooling_device1

[    3.735542] acpi_processor_get_power_info called

[    3.735599] acpi_processor_get_power_info zeroes all c-states

[    3.735659] acpi_processor_get_power_info analyzes cst

[    3.735717] acpi_processor_get_power_info_cst called

[    3.735775] acpi_processor_get_power_info_cst conted

[    3.735834] acpi_processor_get_power_info_cst bad cst

[    3.735892] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.735954] acpi_processor_get_power_info analyzes fadt

[    3.736013] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.736074] acpi_processor_get_power_info we have a result

[    3.736305] processor LNXCPU:02: registered as cooling_device2

 

I did a cat on /proc/acpi/processor/cpu0 files:

 

info

----

processor id:            0

acpi id:                 0

bus mastering control:   yes

power management:        no

throttling control:      no

limit interface:         no

 

limit:

<not supported>

 

power:

------

active state:            C0

max_cstate:              C8

maximum allowed latency: 2000000000 usec

states:

 

throttling:

-----------

<not supported>

 

Carsten.



[-- Attachment #1.2: Type: text/html, Size: 11278 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: RE: RE: RE: RE: RE: RE: No C-States any longer...

[Tian, Kevin]

[-- Attachment #1.1: Type: text/plain, Size: 3505 bytes --]

It then implicates the possibility of a general bug in ACPI on this special AMD box, which then gets fixed in later kernel (so why Konrad's 2.6.39 tree works). It's not Xen/Dom0 specific.

I suggest you move to Konrad's tree when it's ready.

Thanks
Kevin

From: Carsten Schiers [mailto:carsten@schiers.de]
Sent: Friday, June 17, 2011 3:34 AM
To: Tian, Kevin
Cc: Ian.Campbell; Yu, Ke; mark.langsdorf; xen-devel
Subject: AW: RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...


>> So the plan is to run the very kernel (2.6.32.40 from Jeremy's git) natively,

>> without Xen, and check

>> what acpi.debug and my printks are reporting?

>

>yes



Booting the very kernel on bare hardware will not change the way things are running,

despite one small change: the CPUs are registered as "cooling devices" ?!?



[    3.568766] ACPI: Power Button [PWRF]

[    3.734140] acpi_processor_get_power_info called

[    3.734200] acpi_processor_get_power_info zeroes all c-states

[    3.734260] acpi_processor_get_power_info analyzes cst

[    3.734319] acpi_processor_get_power_info_cst called

[    3.734377] acpi_processor_get_power_info_cst conted

[    3.734436] acpi_processor_get_power_info_cst bad cst

[    3.734495] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.734556] acpi_processor_get_power_info analyzes fadt

[    3.734614] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.734675] acpi_processor_get_power_info we have a result

[    3.734774] processor LNXCPU:00: registered as cooling_device0

[    3.734855] acpi_processor_get_power_info called

[    3.734912] acpi_processor_get_power_info zeroes all c-states

[    3.734973] acpi_processor_get_power_info analyzes cst

[    3.735031] acpi_processor_get_power_info_cst called

[    3.735089] acpi_processor_get_power_info_cst conted

[    3.735147] acpi_processor_get_power_info_cst bad cst

[    3.735206] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.735267] acpi_processor_get_power_info analyzes fadt

[    3.735325] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.735386] acpi_processor_get_power_info we have a result

[    3.735463] processor LNXCPU:01: registered as cooling_device1

[    3.735542] acpi_processor_get_power_info called

[    3.735599] acpi_processor_get_power_info zeroes all c-states

[    3.735659] acpi_processor_get_power_info analyzes cst

[    3.735717] acpi_processor_get_power_info_cst called

[    3.735775] acpi_processor_get_power_info_cst conted

[    3.735834] acpi_processor_get_power_info_cst bad cst

[    3.735892] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.735954] acpi_processor_get_power_info analyzes fadt

[    3.736013] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.736074] acpi_processor_get_power_info we have a result

[    3.736305] processor LNXCPU:02: registered as cooling_device2



I did a cat on /proc/acpi/processor/cpu0 files:



info

----

processor id:            0

acpi id:                 0

bus mastering control:   yes

power management:        no

throttling control:      no

limit interface:         no



limit:

<not supported>



power:

------

active state:            C0

max_cstate:              C8

maximum allowed latency: 2000000000 usec

states:



throttling:

-----------

<not supported>



Carsten.

[-- Attachment #1.2: Type: text/html, Size: 17511 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

AW: RE: RE: RE: RE: RE: No C-States any longer...

[Carsten Schiers]

>In your case there's no _CST found, and then no PBLK found. 

The only thing that are giveing me hope are:

  - it worked once (Xenified 2.6.18.8)
  - FADT contains C2/C3 Latency information (_CST Support is 00 BTW)

>do you mean the latest PVOPS from Konzad? I don't think Cstate/Pstate patches
>have been carried there, which still stay in Jeremy's tree.

Currently I tried with stable 2.6.32.x from Jeremy and Debian Squeeze, as Konrad
said, his 2.6.39.x would expose C-States for him, what did not before, I will try
his 2.6.39.x next. I can check this and native boot results tonight.

>Since this is the AMD box which I'm not familiar with, also CC Mark here who is
>the owner for power management on AMD boxes.

Mark, I realy hope you have an idea. This is - by the way - the X3 400e I just bought
because I never succeeded in getting TSC hickup-free >2.6.18 systems with my 4050e, 
you eventually remember...?

Carsten.

RE: RE: RE: RE: RE: RE: No C-States any longer...

[Tian, Kevin]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

> From: Carsten Schiers [mailto:carsten@schiers.de]
> Sent: Thursday, June 16, 2011 2:22 PM
> 
> >In your case there's no _CST found, and then no PBLK found.
> 
> The only thing that are giveing me hope are:
> 
>   - it worked once (Xenified 2.6.18.8)
>   - FADT contains C2/C3 Latency information (_CST Support is 00 BTW)

w/o PBLK, FADT info is incomplete to construct a full Cstate information.

> 
> >do you mean the latest PVOPS from Konzad? I don't think Cstate/Pstate
> patches
> >have been carried there, which still stay in Jeremy's tree.
> 
> Currently I tried with stable 2.6.32.x from Jeremy and Debian Squeeze, as
> Konrad
> said, his 2.6.39.x would expose C-States for him, what did not before, I will try
> his 2.6.39.x next. I can check this and native boot results tonight.

I saw one patch from Konrad which is based on his experimental code. See
attached. You may ask him for the code for your experiment. 

Thanks
Kevin


[-- Attachment #2: Type: message/rfc822, Size: 10857 bytes --]

From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "bderzhavets@yahoo.com" <bderzhavets@yahoo.com>, "Yu, Ke" <ke.yu@intel.com>, "carsten@schiers.de" <carsten@schiers.de>, "JBeulich@novell.com" <JBeulich@novell.com>, Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "tom.goetz@virtualcomputer.com" <tom.goetz@virtualcomputer.com>
Subject: [Xen-devel] [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39)
Date: Wed, 15 Jun 2011 21:46:16 +0800
Message-ID: <20110615134615.GA7529@dumpdata.com>

I was trying to bring up an prototype box and it while it booted fine under
Linux, if I tried to do it under Dom0 with a modified Linux kernel it crashed.
By modified I mean it had the "xen/acpi: add xen acpi processor driver" patch in it.

I traced it down to a one line fix which fixed the issue.
It might make sense to back-port this to the 2.6.32 tree, and it _might_ fix
some problems folks had with the processor_xen module (CC-ed here). If you
see a similar stack trace to the one outlined in the patch - then you might
be hitting this bug.

Anyhow, I am not that familiar with Linux ACPI parser or how the P states
are exposed - so it might be that this patch is completly bogus. Feedback
would be much appreciated.


commit 498adade0091900564e6a6bf06a0f793f09d4764
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Tue Jun 14 21:44:35 2011 -0400

    acpi/xen: Evaluate the _PDC properly.

    The call to evaluate the _PDC was passing in the wrong argument.

    Instead of passing in the acpi_handle it was passing in the structure
    that held the acpi_handle as the second member. This can cause
    the wrong evaluation on some machines ending up in trying to evaluate
    the _PDC and dereferencing the prefix node (which is not part of
    that structure) and causing a NULL pointer exception.

    The results after running with this patch (and yes, there are no _PDC
    on this box):

    nsxfeval-0180 [2017820672] [4294967276] evaluate_object       : ----Entry
    nsxfeval-0359 [2017820672] [4294967276] evaluate_object       : ----Exit- ****Exception****: AE_BAD_PARAMETER
    processor_core-0306 [2017820672] [4294967275] processor_eval_pdc    : Could not evaluate _PDC, using legacy perf. control.
    nsxfeval-0180 [2017820672] [4294967276] evaluate_object       : ----Entry
    nsxfeval-0263 [2017820672] [4294967276] evaluate_object       : pathname is [_PPC]
      nseval-0090 [2017820672] [4294967277] ns_evaluate           : ----Entry
     nsutils-0707 [2017820672] [4294967278] ns_get_node           : ----Entry ffffffff8173d637
     nsutils-0391 [2017820672] [4294967279] ns_internalize_name   : ----Entry
     nsutils-0280 [2017820672] [4294967280] ns_build_internal_name: ----Entry

    Without the patch (I enabled tracing here so there are more details,
    note the prefix scope):

    nsxfeval-0180 [2017820672] [4294967276] evaluate_object       : ----Entry
      utcopy-0641 [2017820672] [4294967277] ut_copy_eobject_to_iob: ----Entry
      utcopy-0459 [2017820672] [4294967278] ut_copy_esimple_to_isi: ----Entry
    utobject-0097 [2017820672] [4294967279] ut_create_internal_obj: ----Entry Buffer
    utobject-0385 [2017820672] [4294967280] ut_allocate_object_des: ----Entry
    utobject-0401 [2017820672] [4294967280] ut_allocate_object_des: ffff8800779748b8 Size 48
    utobject-0403 [2017820672] [4294967280] ut_allocate_object_des: ----Exit- ffff8800779748b8
    utobject-0146 [2017820672] [4294967279] ut_create_internal_obj: ----Exit- ffff8800779748b8
      utcopy-0552 [2017820672] [4294967278] ut_copy_esimple_to_isi: ----Exit- AE_OK
      utcopy-0656 [2017820672] [4294967277] ut_copy_eobject_to_iob: ----Exit- AE_OK
    nsxfeval-0263 [2017820672] [4294967276] evaluate_object       : pathname is [_PDC]
      nseval-0090 [2017820672] [4294967277] ns_evaluate           : ----Entry
     nsutils-0707 [2017820672] [4294967278] ns_get_node           : ----Entry ffffffff81733097
     nsutils-0391 [2017820672] [4294967279] ns_internalize_name   : ----Entry
     nsutils-0280 [2017820672] [4294967280] ns_build_internal_name: ----Entry
     nsutils-0363 [2017820672] [4294967280] ns_build_internal_name: Returning [ffff880069151ef0] (rel) "_PDC"
     nsutils-0366 [2017820672] [4294967280] ns_build_internal_name: ----Exit- AE_OK
     nsutils-0419 [2017820672] [4294967279] ns_internalize_name   : ----Exit- AE_OK
     utmutex-0255 [2017820672] [4294967278] ut_acquire_mutex      : Thread 2017820672 attempting to acquire Mutex [ACPI_MTX_Namespace]
         osl-0973 [2017820672] [4294967278] os_wait_semaphore     : Waiting for semaphore[ffff88007f004280|1|65535]
         osl-0992 [2017820672] [4294967278] os_wait_semaphore     : Acquired semaphore[ffff88007f004280|1|65535] utmutex-0263 [2017820672] [4294967278] ut_acquire_mutex      : Thread 2017820672 acquired Mutex [ACPI_MTX_Namespace]
    nsaccess-0301 [2017820672] [4294967279] ns_lookup             : ----Entry
     nsutils-0663 [2017820672] [4294967280] ns_opens_scope        : ----Entry Untyped
     nsutils-0673 [2017820672] [4294967280] ns_opens_scope        : ----Exit- 0000000000000000
    nsaccess-0398 [2017820672] [4294967279] ns_lookup             : Searching relative to prefix scope [ÿÿÿÿ] (ffff880069163800)
    nsaccess-0510 [2017820672] [4294967279] ns_lookup             : Simple Pathname (1 segment, Flags=2)
      nsdump-0087 [2017820672] [4294967279] ns_print_pathname     : [_PDC]
    nssearch-0297 [2017820672] [4294967280] ns_search_and_enter   : ----Entry
    nssearch-0102 [2017820672] [4294967281] ns_search_one_scope   : ----Entry
     nsnames-0139 [2017820672] [4294967282] ns_get_external_pathna: ----Entry ffff880069163800
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000418
    IP: [<ffffffff8129266f>] acpi_ns_get_pathname_length+0x1f/0x68
    .. snip..
    Pid: 1, comm: swapper Not tainted 2.6.39.1-00221-gbb09547 #1 Intel Corporation S2600CP/S2600CP
    .. snip..
    Call Trace:
     [<ffffffff81292905>] acpi_ns_get_external_pathname+0x38/0x137
     [<ffffffff81290a1f>] acpi_ns_search_one_scope+0x4b/0x1f5
     [<ffffffff81290cfa>] acpi_ns_search_and_enter+0x131/0x42f
     [<ffffffff81290310>] acpi_ns_lookup+0x4c8/0x6c9
     [<ffffffff812933e3>] acpi_ns_get_node+0xe8/0x16e
     [<ffffffff812920bf>] acpi_ns_evaluate+0x83/0x3b6
     [<ffffffff812916f7>] acpi_evaluate_object+0x1f9/0x35b
     [<ffffffff81123d7b>] ? kmem_cache_alloc_trace+0xa0/0xb0
     [<ffffffff814a4e35>] acpi_processor_set_pdc+0x1cc/0x226
     [<ffffffff814a5a1e>] xen_acpi_processor_add+0x45c/0x59d

    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 43760f8..db54525 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -311,7 +311,7 @@ static int __cpuinit xen_acpi_processor_add(struct acpi_device *device)
        }

        /* _PDC call should be done before doing anything else (if reqd.). */
-       acpi_processor_set_pdc(pr);
+       acpi_processor_set_pdc(pr->handle);

 #ifdef CONFIG_CPU_FREQ
        xen_acpi_processor_ppc_has_changed(pr);

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

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

AW: RE: RE: RE: RE: RE: No C-States any longer...

[Carsten Schiers]

> this looks a bit strange. how about the native log?

I have not done a log with ACPI_DEBUG enabled. Will do so tonight or tomorrow night.

> what's your dom0 vcpu number? and how about physical cpu?

dom0_vcpu_pin/xend-config.sxp result in the following excerpt of xm vcpu-list:

  Name          ID          VCPU          CPU           State          ...
  Domain-0      0           0             0             r--            ...

  Domain-0      0           1             -             --p            ...

  Domain-0      0           2             -             --p            ...
  ...

> there's possibility that in your environment general ACPI code
> is changed which is not reflected in Xen specific versions. 

I have not understood that.

Thanks,
Carsten.

RE: RE: RE: RE: RE: RE: No C-States any longer...

[Tian, Kevin]

> From: Carsten Schiers [mailto:carsten@schiers.de]
> Sent: Wednesday, June 15, 2011 5:12 PM
> 
> > this looks a bit strange. how about the native log?
> 
> I have not done a log with ACPI_DEBUG enabled. Will do so tonight or
> tomorrow night.
> 
> > what's your dom0 vcpu number? and how about physical cpu?
> 
> dom0_vcpu_pin/xend-config.sxp result in the following excerpt of xm vcpu-list:
> 
>   Name          ID          VCPU          CPU
> State          ...
>   Domain-0      0           0             0
> r--            ...
> 
>   Domain-0      0           1             -
> --p            ...
> 
>   Domain-0      0           2             -
> --p            ...
>   ...
> 
> > there's possibility that in your environment general ACPI code
> > is changed which is not reflected in Xen specific versions.
> 
> I have not understood that.
> 

as you see already, there's some ACPI function duplicated into a Xen specific
version to handle some tricky assumptions, such as xen_acpi_processor_get_power_info.
So it's possible that, if same kernel works well natively, those Xen stubs are out of
sync with original version. This is not a clean approach, and we need consider a better
one for pushing them upstream. :/

Thanks
Kevin

RE: RE: RE: RE: RE: No C-States any longer...

[Tian, Kevin]

> From: Carsten Schiers [mailto:carsten@schiers.de]
> Sent: Saturday, June 11, 2011 5:26 PM
> 
> I switched on ACPI_DEBUG but the result is not surprising:
> 
> Jun 11 10:56:48 data kernel: [  186.897468]  nsutils-0461
> [ffff880002b1db00] [00] ns_build_internal_name: Returning
> [ffff88000ed14988] (rel) "_CST"
> Jun 11 10:56:48 data kernel: [  186.897473]  utmutex-0257
> [ffff880002b1db00] [00] ut_acquire_mutex      : Thread ffff880002b1db00
> attempting to acquire Mutex [ACPI_MTX_Namespace]
> Jun 11 10:56:48 data kernel: [  186.897479]      osl-0872
> [ffff880002b1db00] [00] os_wait_semaphore     : Waiting for
> semaphore[ffff88000fc2e1e0|1|65535]
> Jun 11 10:56:48 data kernel: [  186.897485]      osl-0891
> [ffff880002b1db00] [00] os_wait_semaphore     : Acquired
> semaphore[ffff88000fc2e1e0|1|65535] utmutex-0265 [ffff880002b1db00] [00]
> ut_acquire_mutex      : Thread ffff880002b1db00 acquired Mutex
> [ACPI_MTX_Namespace]
> Jun 11 10:56:48 data kernel: [  186.897496] nsaccess-0399
> [ffff880002b1db00] [00] ns_lookup             : Searching relative to
> prefix scope [C002] (ffff88000fc2e4a0)
> Jun 11 10:56:48 data kernel: [  186.897501] nsaccess-0511
> [ffff880002b1db00] [00] ns_lookup             : Simple Pathname (1
> segment, Flags=2)
> Jun 11 10:56:48 data kernel: [  186.897506]   nsdump-0087
> [ffff880002b1db00] [00] ns_print_pathname     : [_CST]
> Jun 11 10:56:48 data kernel: [  186.897515] nssearch-0114
> [ffff880002b1db00] [00] ns_search_one_scope   : Searching \_PR_.C002
> (ffff88000fc2e4a0) For [_CST] (Untyped)
> Jun 11 10:56:48 data kernel: [  186.897521] nssearch-0179
> [ffff880002b1db00] [00] ns_search_one_scope   : Name [_CST] (Untyped)
> not found in search in scope [C002] ffff88000fc2e4a0 first child
> ffff88000fa54700
> Jun 11 10:56:48 data kernel: [  186.897528] nssearch-0390
> [ffff880002b1db00] [00] ns_search_and_enter   : _CST Not found in
> ffff88000fc2e4a0 [Not adding]
> Jun 11 10:56:48 data kernel: [  186.897533] nsaccess-0572
> [ffff880002b1db00] [00] ns_lookup             : Name [_CST] not found in
> scope [C002] ffff88000fc2e4a0
> Jun 11 10:56:48 data kernel: [  186.897539]  nsutils-0876
> [ffff880002b1db00] [00] ns_get_node           : _CST, AE_NOT_FOUND
> Jun 11 10:56:48 data kernel: [  186.897544]  utmutex-0299
> [ffff880002b1db00] [00] ut_release_mutex      : Thread ffff880002b1db00
> releasing Mutex [ACPI_MTX_Namespace]
> Jun 11 10:56:48 data kernel: [  186.897549]      osl-0911
> [ffff880002b1db00] [00] os_signal_semaphore   : Signaling
> semaphore[ffff88000fc2e1e0|1]
> Jun 11 10:56:48 data kernel: [  186.897555]
> acpi_processor_get_power_info_cst bad cst
> Jun 11 10:56:48 data kernel: [  186.897557] processor_idle-0363
> [ffff880002b1db00] [00] processor_get_power_in: No _CST, giving up
> Jun 11 10:56:48 data kernel: [  186.897562]
> acpi_processor_get_power_info result=-19, -ENODEV=-19
> Jun 11 10:56:48 data kernel: [  186.897563]
> acpi_processor_get_power_info analyzes fadt
> Jun 11 10:56:48 data kernel: [  186.897565]
> acpi_processor_get_power_info result=-19, -ENODEV=-19
> Jun 11 10:56:48 data kernel: [  186.897567]
> acpi_processor_get_power_info we have a result
> Jun 11 10:56:48 data kernel: [  186.897569]
> xen_acpi_processor_get_power_info returns=-19
> Jun 11 10:56:48 data kernel: [  186.897570]
> xen_acpi_processor_power_init got power info
> Jun 11 10:56:48 data kernel: [  186.897572]
> xen_acpi_processor_power_init not power flags
> Jun 11 10:56:48 data kernel: [  186.897574]     scan-0568
> [ffff880002b1db00] [00] bus_driver_init       : Driver successfully
> bound to device
> Jun 11 10:56:48
> 
> It doesn't find _CST, as we did not in the extract of acpiextract.
> Unfortunately, the old, working Xen 4.1.0/Linux 2.6.18 combo doesn't
> boot any longer, because
> I upgraded to Debian Squeeze already and something doesn't work with the
> udev version. I will try to boot native Linux in order to verify 100%
> that the tables
> are there.

yes, that's interesting data to compare.

> 
> If we already assume this, the cause should be in the way how pvops
> Linux is mapping the tables into the system, shouldn't it`

Or the DSDT table may be corrupted by some undesired operation, however
random corruption may lead to more errors than missing _CST here. Did you
change BIOS setting recently?

Thanks
Kevin 

AW: RE: RE: RE: RE: RE: No C-States any longer...

[Carsten Schiers]

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

AW: RE: RE: RE: RE: RE: No C-States any longer...

[Carsten Schiers]

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)

It does this for all processors. pr_id is always -1, pr->acpi_id 
counting up from 0 to 2.

Any help is welcome, but I will analyze further...

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@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: RE: RE: RE: RE: RE: No C-States any longer...

[Tian, Kevin]

> From: Carsten Schiers [mailto:carsten@schiers.de]
> 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?

> 
> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

RE: RE: RE: RE: RE: RE: No C-States any longer...

[Ian Campbell]

On Wed, 2011-06-15 at 09:11 +0100, Tian, Kevin wrote:
> > From: Carsten Schiers [mailto:carsten@schiers.de]
> > 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@intel.com>
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@intel.com>
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

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@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

RE: RE: RE: RE: RE: RE: No C-States any longer...

[Tian, Kevin]

[-- Attachment #1: Type: text/plain, Size: 4329 bytes --]

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Wednesday, June 15, 2011 4:35 PM
> 
> On Wed, 2011-06-15 at 09:11 +0100, Tian, Kevin wrote:
> > > From: Carsten Schiers [mailto:carsten@schiers.de]
> > > 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.

yes, the existing tricky changes are mostly used to tackle this disconnection.

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

We don't want to add that limitation to have dom0 vcpu number same as 
physical cpu number to use PM features. But yes Carsten can try use
same number to see whether it works for him. If it works, then there's other
corner cases we didn't capture. But since this works on his Intel box, which
I guess same configuration is used, I'd think it may come from some oddity
in AMD box's ACPI table which is not well handled by either common ACPI
code or Xen specific stubs.

Thanks
Kevin

> 
> This changeset refers to the -1 too:
> 
> commit 68320323a51c2378aca433c76157d9e66104ff1e
> Author: Jiang, Yunhong <yunhong.jiang@intel.com>
> 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@intel.com>
>     Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> 
> 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@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> > >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 


[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: RE: RE: RE: RE: RE: No C-States any longer...

[Tian, Kevin]

> From: Carsten Schiers [mailto:carsten@schiers.de]
> Sent: Monday, June 13, 2011 9:22 PM
> 
> >>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.

Is your native linux with same version as dom0? It's better to use a same
version native kernel to make sure that this is not a generic ACPI bug. There
tends to various issues regarding to ACPI power management time to time
on different machines, which happens on native linux too. If you can confirm
this point, then we may reduce the area down to xen specific acpi stubs. :-)

Thanks
Kevin