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 22, 2011 7:36 PM
> 
> >> 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
> >then such ACPI Cstate information is not gathered, the kernel always
> >invokes hlt when system is idle which achieves the effect. :-)
> 
> After having had some discussion with Gigabyte, I am now sure that the BIOS
> intentionally doesn't implement C-States at all. Gigabyte says, they
> iomplemeted
> Cool'n'Quiet "instead".

great that this is clarified from the vendor. :-)

> 
> In don't share this point, as I think Spec does require either _CST or PBLK.
> Nevertheless, I think to remember that
> 
>   - xenpm did only mention C0 and C1 in the past
>   - but xenpm did so and does not any longer

there're always various ACPI-incompatible boxes in the market, and the reason 
for
the different behavior may come from the fact that newer kernel more conforms
to the ACPI spec now.

> 
> Eventually, even if it's only cosmetic, something needs to be changed in order
> to reflect that case by setting up C1 in such a case. I am sorry, but I was 
> not
> able to do it.

I agree that from statistics p.o.v, C1/C0 should be always exposed regardless of
whether ACPI is broken.

Thanks
Kevin


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