* [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39)
@ 2011-06-15 13:46 Konrad Rzeszutek Wilk
2011-06-15 14:15 ` Jan Beulich
2011-06-16 2:57 ` Tian, Kevin
0 siblings, 2 replies; 5+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-06-15 13:46 UTC (permalink / raw)
To: bderzhavets, ke.yu, carsten, JBeulich, Jeremy Fitzhardinge,
xen-devel, tom.goetz
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);
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39)
2011-06-15 13:46 [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39) Konrad Rzeszutek Wilk
@ 2011-06-15 14:15 ` Jan Beulich
2011-06-15 15:00 ` Konrad Rzeszutek Wilk
2011-06-16 2:57 ` Tian, Kevin
1 sibling, 1 reply; 5+ messages in thread
From: Jan Beulich @ 2011-06-15 14:15 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Jeremy Fitzhardinge, xen-devel, bderzhavets, ke.yu, carsten,
tom.goetz
>>> On 15.06.11 at 15:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 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
The parameter type change happened in 2.6.33.
Jan
> 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] [4
294967280] 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);
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Re: [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39)
2011-06-15 14:15 ` Jan Beulich
@ 2011-06-15 15:00 ` Konrad Rzeszutek Wilk
2011-06-15 15:18 ` Jan Beulich
0 siblings, 1 reply; 5+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-06-15 15:00 UTC (permalink / raw)
To: Jan Beulich
Cc: Jeremy Fitzhardinge, xen-devel, bderzhavets, ke.yu, carsten,
tom.goetz
On Wed, Jun 15, 2011 at 03:15:59PM +0100, Jan Beulich wrote:
> >>> On 15.06.11 at 15:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > 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
>
> The parameter type change happened in 2.6.33.
Aha! That would explain why it was there - thank you for your sharp eye.
BTW, are there any good materials on explaining _PSS, _PDC, _P.. and C-states
and how to read the ACPI DSDT/SSDT to figure out what it has?
One of my AMD boxes on baremetal finds the _PSS tables but when
I boot under Xen it tells me it can't find it - and I am not even sure what they
look like in the ACPI tables.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Re: [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39)
2011-06-15 15:00 ` Konrad Rzeszutek Wilk
@ 2011-06-15 15:18 ` Jan Beulich
0 siblings, 0 replies; 5+ messages in thread
From: Jan Beulich @ 2011-06-15 15:18 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Jeremy Fitzhardinge, xen-devel, bderzhavets, ke.yu, carsten,
tom.goetz
>>> On 15.06.11 at 17:00, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> BTW, are there any good materials on explaining _PSS, _PDC, _P.. and C-states
I only know of the specification itself, ...
> and how to read the ACPI DSDT/SSDT to figure out what it has?
... and disassembling the acpidump-ed/acpixtract-ed binary tables
with iasl.
Jan
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39)
2011-06-15 13:46 [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39) Konrad Rzeszutek Wilk
2011-06-15 14:15 ` Jan Beulich
@ 2011-06-16 2:57 ` Tian, Kevin
1 sibling, 0 replies; 5+ messages in thread
From: Tian, Kevin @ 2011-06-16 2:57 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, bderzhavets@yahoo.com, Yu, Ke,
carsten@schiers.de, JBeulich
> From: Konrad Rzeszutek Wilk
> Sent: Wednesday, June 15, 2011 9:46 PM
>
> 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.
this is a bug triggered by rebase. :-)
In 2.6.32:
static int acpi_processor_set_pdc(struct acpi_processor *pr)
In 3.0:
void __cpuinit acpi_processor_set_pdc(acpi_handle handle)
>
> 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.
the patch is of course correct in 3.0 context.
Thanks
Kevin
>
>
> 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);
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-06-16 2:57 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-15 13:46 [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39) Konrad Rzeszutek Wilk
2011-06-15 14:15 ` Jan Beulich
2011-06-15 15:00 ` Konrad Rzeszutek Wilk
2011-06-15 15:18 ` Jan Beulich
2011-06-16 2:57 ` Tian, Kevin
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.