From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bderzhavets@yahoo.com, ke.yu@intel.com, carsten@schiers.de,
JBeulich@novell.com, Jeremy Fitzhardinge <jeremy@goop.org>,
xen-devel@lists.xensource.com, tom.goetz@virtualcomputer.com
Subject: [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39)
Date: Wed, 15 Jun 2011 09:46:16 -0400 [thread overview]
Message-ID: <20110615134615.GA7529@dumpdata.com> (raw)
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@oracle.com>
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@oracle.com>
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);
next reply other threads:[~2011-06-15 13:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-15 13:46 Konrad Rzeszutek Wilk [this message]
2011-06-15 14:15 ` [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39) Jan Beulich
2011-06-15 15:00 ` Konrad Rzeszutek Wilk
2011-06-15 15:18 ` Jan Beulich
2011-06-16 2:57 ` Tian, Kevin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110615134615.GA7529@dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@novell.com \
--cc=bderzhavets@yahoo.com \
--cc=carsten@schiers.de \
--cc=jeremy@goop.org \
--cc=ke.yu@intel.com \
--cc=tom.goetz@virtualcomputer.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.