| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: RE: RE: RE: [Xen-devel] No C-States any longer...
> 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
|
|
|
| |
|
Home