RE: RE: RE: RE: No C-States any longer...

RE: RE: RE: RE: No C-States any longer...

[Tian, Kevin]

> From: Carsten Schiers [mailto:carsten@schiers.de]
> 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

RE: RE: RE: RE: No C-States any longer...

[Tian, Kevin]

> From: Carsten Schiers [mailto:carsten@schiers.de]
> 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

AW: RE: RE: RE: No C-States any longer...

[Carsten Schiers]

>> 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". 

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

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 simply bought a new board...

Thanks for everybodies help. If someone ever changes the code, I have some days
left to check it.

Carsten.

RE: RE: RE: RE: No C-States any longer...

[Tian, Kevin]

> From: Carsten Schiers [mailto:carsten@schiers.de]
> 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

Re: RE: RE: RE: No C-States any longer...

[Konrad Rzeszutek Wilk]

> I simply bought a new board...

Heh. Easy solution .. :-)