WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Carsten Schiers <carsten@xxxxxxxxxx>, "mark.langsdorf@xxxxxxx" <mark.langsdorf@xxxxxxx>
Subject: RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 16 Jun 2011 14:30:20 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Ian, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Campbell <Ian.Campbell@xxxxxxxxxx>, "Yu, Ke" <ke.yu@xxxxxxxxx>
Delivery-date: Wed, 15 Jun 2011 23:32:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <2528978.431308205342002.JavaMail.root@uhura>
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: <2528978.431308205342002.JavaMail.root@uhura>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acwr7cmfIqr/j9TrTi26dqY47Ff82AAAGijQ
Thread-topic: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
> From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
> Sent: Thursday, June 16, 2011 2:22 PM
> 
> >In your case there's no _CST found, and then no PBLK found.
> 
> The only thing that are giveing me hope are:
> 
>   - it worked once (Xenified 2.6.18.8)
>   - FADT contains C2/C3 Latency information (_CST Support is 00 BTW)

w/o PBLK, FADT info is incomplete to construct a full Cstate information.

> 
> >do you mean the latest PVOPS from Konzad? I don't think Cstate/Pstate
> patches
> >have been carried there, which still stay in Jeremy's tree.
> 
> Currently I tried with stable 2.6.32.x from Jeremy and Debian Squeeze, as
> Konrad
> said, his 2.6.39.x would expose C-States for him, what did not before, I will 
> try
> his 2.6.39.x next. I can check this and native boot results tonight.

I saw one patch from Konrad which is based on his experimental code. See
attached. You may ask him for the code for your experiment. 

Thanks
Kevin

--- Begin Message ---
To: "bderzhavets@xxxxxxxxx" <bderzhavets@xxxxxxxxx>, "Yu, Ke" <ke.yu@xxxxxxxxx>, "carsten@xxxxxxxxxx" <carsten@xxxxxxxxxx>, "JBeulich@xxxxxxxxxx" <JBeulich@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "tom.goetz@xxxxxxxxxxxxxxxxxxx" <tom.goetz@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39)
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Wed, 15 Jun 2011 21:46:16 +0800
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" <xen-devel-bounces@xxxxxxxxxxxxxxxxxxx>
Thread-index: AcwrY5G/LGsymZNqSpmTeGPX+f+Ejw==
Thread-topic: [Xen-devel] [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39)
User-agent: Mutt/1.5.21 (2010-09-15)
I was trying to bring up an prototype box and it while it booted fine under
Linux, if I tried to do it under Dom0 with a modified Linux kernel it crashed.
By modified I mean it had the "xen/acpi: add xen acpi processor driver" patch 
in it.

I traced it down to a one line fix which fixed the issue.
It might make sense to back-port this to the 2.6.32 tree, and it _might_ fix
some problems folks had with the processor_xen module (CC-ed here). If you
see a similar stack trace to the one outlined in the patch - then you might
be hitting this bug.

Anyhow, I am not that familiar with Linux ACPI parser or how the P states
are exposed - so it might be that this patch is completly bogus. Feedback
would be much appreciated.


commit 498adade0091900564e6a6bf06a0f793f09d4764
Author: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date:   Tue Jun 14 21:44:35 2011 -0400

    acpi/xen: Evaluate the _PDC properly.

    The call to evaluate the _PDC was passing in the wrong argument.

    Instead of passing in the acpi_handle it was passing in the structure
    that held the acpi_handle as the second member. This can cause
    the wrong evaluation on some machines ending up in trying to evaluate
    the _PDC and dereferencing the prefix node (which is not part of
    that structure) and causing a NULL pointer exception.

    The results after running with this patch (and yes, there are no _PDC
    on this box):

    nsxfeval-0180 [2017820672] [4294967276] evaluate_object       : ----Entry
    nsxfeval-0359 [2017820672] [4294967276] evaluate_object       : ----Exit- 
****Exception****: AE_BAD_PARAMETER
    processor_core-0306 [2017820672] [4294967275] processor_eval_pdc    : Could 
not evaluate _PDC, using legacy perf. control.
    nsxfeval-0180 [2017820672] [4294967276] evaluate_object       : ----Entry
    nsxfeval-0263 [2017820672] [4294967276] evaluate_object       : pathname is 
[_PPC]
      nseval-0090 [2017820672] [4294967277] ns_evaluate           : ----Entry
     nsutils-0707 [2017820672] [4294967278] ns_get_node           : ----Entry 
ffffffff8173d637
     nsutils-0391 [2017820672] [4294967279] ns_internalize_name   : ----Entry
     nsutils-0280 [2017820672] [4294967280] ns_build_internal_name: ----Entry

    Without the patch (I enabled tracing here so there are more details,
    note the prefix scope):

    nsxfeval-0180 [2017820672] [4294967276] evaluate_object       : ----Entry
      utcopy-0641 [2017820672] [4294967277] ut_copy_eobject_to_iob: ----Entry
      utcopy-0459 [2017820672] [4294967278] ut_copy_esimple_to_isi: ----Entry
    utobject-0097 [2017820672] [4294967279] ut_create_internal_obj: ----Entry 
Buffer
    utobject-0385 [2017820672] [4294967280] ut_allocate_object_des: ----Entry
    utobject-0401 [2017820672] [4294967280] ut_allocate_object_des: 
ffff8800779748b8 Size 48
    utobject-0403 [2017820672] [4294967280] ut_allocate_object_des: ----Exit- 
ffff8800779748b8
    utobject-0146 [2017820672] [4294967279] ut_create_internal_obj: ----Exit- 
ffff8800779748b8
      utcopy-0552 [2017820672] [4294967278] ut_copy_esimple_to_isi: ----Exit- 
AE_OK
      utcopy-0656 [2017820672] [4294967277] ut_copy_eobject_to_iob: ----Exit- 
AE_OK
    nsxfeval-0263 [2017820672] [4294967276] evaluate_object       : pathname is 
[_PDC]
      nseval-0090 [2017820672] [4294967277] ns_evaluate           : ----Entry
     nsutils-0707 [2017820672] [4294967278] ns_get_node           : ----Entry 
ffffffff81733097
     nsutils-0391 [2017820672] [4294967279] ns_internalize_name   : ----Entry
     nsutils-0280 [2017820672] [4294967280] ns_build_internal_name: ----Entry
     nsutils-0363 [2017820672] [4294967280] ns_build_internal_name: Returning 
[ffff880069151ef0] (rel) "_PDC"
     nsutils-0366 [2017820672] [4294967280] ns_build_internal_name: ----Exit- 
AE_OK
     nsutils-0419 [2017820672] [4294967279] ns_internalize_name   : ----Exit- 
AE_OK
     utmutex-0255 [2017820672] [4294967278] ut_acquire_mutex      : Thread 
2017820672 attempting to acquire Mutex [ACPI_MTX_Namespace]
         osl-0973 [2017820672] [4294967278] os_wait_semaphore     : Waiting for 
semaphore[ffff88007f004280|1|65535]
         osl-0992 [2017820672] [4294967278] os_wait_semaphore     : Acquired 
semaphore[ffff88007f004280|1|65535] utmutex-0263 [2017820672] [4294967278] 
ut_acquire_mutex      : Thread 2017820672 acquired Mutex [ACPI_MTX_Namespace]
    nsaccess-0301 [2017820672] [4294967279] ns_lookup             : ----Entry
     nsutils-0663 [2017820672] [4294967280] ns_opens_scope        : ----Entry 
Untyped
     nsutils-0673 [2017820672] [4294967280] ns_opens_scope        : ----Exit- 
0000000000000000
    nsaccess-0398 [2017820672] [4294967279] ns_lookup             : Searching 
relative to prefix scope [ÿÿÿÿ] (ffff880069163800)
    nsaccess-0510 [2017820672] [4294967279] ns_lookup             : Simple 
Pathname (1 segment, Flags=2)
      nsdump-0087 [2017820672] [4294967279] ns_print_pathname     : [_PDC]
    nssearch-0297 [2017820672] [4294967280] ns_search_and_enter   : ----Entry
    nssearch-0102 [2017820672] [4294967281] ns_search_one_scope   : ----Entry
     nsnames-0139 [2017820672] [4294967282] ns_get_external_pathna: ----Entry 
ffff880069163800
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000418
    IP: [<ffffffff8129266f>] acpi_ns_get_pathname_length+0x1f/0x68
    .. snip..
    Pid: 1, comm: swapper Not tainted 2.6.39.1-00221-gbb09547 #1 Intel 
Corporation S2600CP/S2600CP
    .. snip..
    Call Trace:
     [<ffffffff81292905>] acpi_ns_get_external_pathname+0x38/0x137
     [<ffffffff81290a1f>] acpi_ns_search_one_scope+0x4b/0x1f5
     [<ffffffff81290cfa>] acpi_ns_search_and_enter+0x131/0x42f
     [<ffffffff81290310>] acpi_ns_lookup+0x4c8/0x6c9
     [<ffffffff812933e3>] acpi_ns_get_node+0xe8/0x16e
     [<ffffffff812920bf>] acpi_ns_evaluate+0x83/0x3b6
     [<ffffffff812916f7>] acpi_evaluate_object+0x1f9/0x35b
     [<ffffffff81123d7b>] ? kmem_cache_alloc_trace+0xa0/0xb0
     [<ffffffff814a4e35>] acpi_processor_set_pdc+0x1cc/0x226
     [<ffffffff814a5a1e>] xen_acpi_processor_add+0x45c/0x59d

    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>

diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 43760f8..db54525 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -311,7 +311,7 @@ static int __cpuinit xen_acpi_processor_add(struct 
acpi_device *device)
        }

        /* _PDC call should be done before doing anything else (if reqd.). */
-       acpi_processor_set_pdc(pr);
+       acpi_processor_set_pdc(pr->handle);

 #ifdef CONFIG_CPU_FREQ
        xen_acpi_processor_ppc_has_changed(pr);

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

--- End Message ---
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel