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

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

> From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
> Sent: Thursday, June 16, 2011 2:48 PM
> 
> Maybe a dump question, but in the beginning of our discussion, we had:
> 
> >> In drivers/scpi/processor_idle.c:
> ...
> >> 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
> 
> There is a comment in acpi_processor_get_power_info_default it is
> said that all processors need to support C1 at least. So (hypothesis),
> if my BIOS is not implemented as specified (neither _CST nor PBLK),
> shouldn't acpi_processor_get_power_info_default also bee called on my
> machine? Is the code exiting too early?
> 

You can argue that point. It exits at current point because typical BIOS 
provide either CST or valid FADT/PBLK info. Of course even when ACPI
table is broken we can still make a valid C1 entry. But also note that even
when such ACPI Cstate information is not gathered, the kernel always
invokes hlt when system is idle which achieves the effect. :-)

Thanks
Kevin

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