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


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

To: "kevin.tian" <kevin.tian@xxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: AW: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
From: "Carsten Schiers" <carsten@xxxxxxxxxx>
Date: Sun, 12 Jun 2011 12:24:22 +0200
Delivery-date: Sun, 12 Jun 2011 03:25:22 -0700
Dkim-signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=date: from:to:message-id:in-reply-to:subject:mime-version:content-type; q= dns/txt; s=beta; bh=d0AWxqxRGU895Ofs11YZ0YXiDX/OA10h2sVrfG+R8NQ=; b= VJV6AKaB6E/2Xual1axh/Tu3Ej9LWaIKWwhZW8a8LyVclclYuRTdCcVKfarVfv5x q79Doz1E8uTqrFxLX8vCwMo5m/SmC8gxO6UCSyrwMsZajcF3zqbOGPC+iiGkLoMY 6hEP0OiYtxOpDnq6EvyfXdFvQmbMhgG9Y6MND+xB5ME=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <625BA99ED14B2D499DC4E29D8138F1505D1B363F9C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
There are some information in FACP (attached), there is no FADT.

In order to test native Linux, I need some more days. Family & Barbecue 
have higher Prio ;o).


-----Ursprüngliche Nachricht-----
Von: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx] 
Gesendet: Sonntag, 12. Juni 2011 10:57
An: Carsten Schiers; xen-devel
Betreff: RE: 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. 
> 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 
information. Could you compare with your working pvops dom0 version or
compare with generic linux to see any difference? This parse logic 
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 
> is to be checked next).

Anyway, you seems close to the root cause...

Attachment: FACP.dsl
Description: Binary data

Xen-devel mailing list