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
|
<Prev in Thread] |
Current Thread |
[Next in Thread> |
- Re: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer..., (continued)
|
|
|