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

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

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
> 

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.

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

[Carsten Schiers]

> Is your native linux with same version as dom0?

Not in this case, sorry. I used a Knoppix Live Linux CD.

> It's better to use a same version native kernel to make sure that this is not 
> a generic ACPI bug. 

Check is scheduled ;o).

Thanks,
Carsten.

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

[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

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.