Konrad Rzeszutek Wilk
2011-Jun-15 13:46 UTC
[Xen-devel] [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39)
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); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2011-Jun-15 14:15 UTC
[Xen-devel] Re: [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39)
>>> 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_ fixThe 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] [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
Konrad Rzeszutek Wilk
2011-Jun-15 15:00 UTC
Re: [Xen-devel] Re: [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39)
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2011-Jun-15 15:18 UTC
Re: [Xen-devel] Re: [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39)
>>> 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-statesI 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tian, Kevin
2011-Jun-16 02:57 UTC
RE: [Xen-devel] [RFC PATCH] acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39)
> 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel