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