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

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

> From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
> Sent: Friday, June 10, 2011 10:56 PM
> 
> Some in-between notes, if someone is better in analyzing the code. There
> is the following sequence
> In drivers/scpi/processor_idle.c:
> 
>         result = acpi_processor_get_power_info_cst(pr);
> 
>         if (result == -ENODEV)
>                 result = acpi_processor_get_power_info_fadt(pr);
> 
>         if (result)
>                 return result;
> 
>         acpi_processor_get_power_info_default(pr);
> 
> On a working Intel machine, it will go through it like this:
> 
>   - acpi_processor_get_power_info_cst, which returns 0
>   - acpi_processor_get_power_info_default
>   - later acpi_processor_power_verify will find some c-states

this is expected sequence

> 
> On my non-working AMD machine, it will go through like this:
>   - acpi_processor_get_power_info_cst, which returns -ENODEV
>   - acpi_processor_get_power_info_fadt, which also return -ENODEV
>   - this result is returned

though CST is optional, it's weird that even FADT doesn't contain valid Cx
information. Could you compare with your working pvops dom0 version or
compare with generic linux to see any difference? This parse logic should
be generic for both Linux and Xen.

> 
> The returned result -ENODEV is cascaded up to the call in
> xen_acpi_processor_power_init, but there
> nothing is checked or done.
> 
> I will now try to find the root cause (acpi_processor_get_power_info_cst
> is to be checked next).

Anyway, you seems close to the root cause...
Thanks
Kevin


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