RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
> 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

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