This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: RE: RE: RE: [Xen-devel] No C-States any longer...

To: Carsten Schiers <carsten@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Sun, 12 Jun 2011 16:57:20 +0800
Accept-language: en-US
Acceptlanguage: en-US
Delivery-date: Sun, 12 Jun 2011 02:01:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <H0000067000b1394.1307717776.uhura.space.zz@MHS>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <625BA99ED14B2D499DC4E29D8138F1505CC5DB58AC@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <H0000067000b1394.1307717776.uhura.space.zz@MHS>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acwnfpo90s2iiK5WTXW1oGc5NnEh9ABX9VVQ
Thread-topic: RE: RE: RE: [Xen-devel] No C-States any longer...
> From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
> 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...

Xen-devel mailing list