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

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 .. :-)

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

[Carsten Schiers]

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?

Carsten.

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

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

[Tian, Kevin]

> From: Carsten Schiers [mailto:carsten@schiers.de]
> Sent: Friday, June 10, 2011 3:09 AM
> 
> Through some adding of printk I was able at least to verify that for my
> 3 core CPU AMD Athlon X3 400e
> 
>   - xen_px_notifier is called six times
>   - Hypervisor is reporting XEN_PM_PX is called six times
>   - Hypervisor is never reporting XEN_PM_CX to have been called
>   - this is because xen_cx_notifier is never called.
>   -> set_cx_pminfo is never called.
> 
> What I will try to find out next is to check where xen_cx_notifier
> *should* be called. OS debugging is
> not realy my expertise, let's see whether you first can give me a hint
> or whether I am quicker to find
> it on my own.
> 

the entry point in dom0 looks like:

xen_acpi_processor_start
	xen_acpi_processor_power_init
		processor_cntl_xen_notify
			xen_ops.pm_ops
				xen_cx_notifier
					HYPERVISOR_dom0_op

Thanks
Kevin

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

[Carsten Schiers]

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

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

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

Carsten.


-----Ursprüngliche Nachricht-----
Von: Tian, Kevin [mailto:kevin.tian@intel.com] 
Gesendet: Freitag, 10. Juni 2011 10:49
An: Carsten Schiers; xen-devel
Betreff: RE: RE: RE: [Xen-devel] No C-States any longer...

> From: Carsten Schiers [mailto:carsten@schiers.de]
> Sent: Friday, June 10, 2011 3:09 AM
> 
> Through some adding of printk I was able at least to verify that for 
my
> 3 core CPU AMD Athlon X3 400e
> 
>   - xen_px_notifier is called six times
>   - Hypervisor is reporting XEN_PM_PX is called six times
>   - Hypervisor is never reporting XEN_PM_CX to have been called
>   - this is because xen_cx_notifier is never called.
>   -> set_cx_pminfo is never called.
> 
> What I will try to find out next is to check where xen_cx_notifier
> *should* be called. OS debugging is
> not realy my expertise, let's see whether you first can give me a hint
> or whether I am quicker to find
> it on my own.
> 

the entry point in dom0 looks like:

xen_acpi_processor_start
	xen_acpi_processor_power_init
		processor_cntl_xen_notify
			xen_ops.pm_ops
				xen_cx_notifier
					HYPERVISOR_dom0_op

Thanks
Kevin

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