Skip to contentSkip to conversation

acpi/xen: Evaluate the _PDC properly (for 2.6.32, and 2.6.39)

RFC PATCH In review Konrad Rzeszutek Wilk 3 participants 5 messages Jun 15, 2011 – Jun 16, 2011 ACPI

lore
Share & tools
lore
#0 lore raw

RFC PATCH 1/1 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 <[email protected]>
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 <[email protected]>
drivers/acpi/processor_xen.c +1 -1
index 43760f8..db54525 100644
@@ -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);
#1 lore raw
Quoted 9 lines
Quoted 1 line
Quoted 1 line · Konrad Rzeszutek Wilk

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

Quoted 59 lines

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 <[email protected]>
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

Quoted 8 lines
    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

Quoted 61 lines

[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 <[email protected]>
drivers/acpi/processor_xen.c +1 -1
index 43760f8..db54525 100644
@@ -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);

#2 lore raw
Quoted 11 lines · Jan Beulich
Quoted 9 lines
Quoted 1 line
Quoted 1 line · Konrad Rzeszutek Wilk

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.

#3 lore raw
Quoted 2 lines
Quoted 1 line
Quoted 1 line · Konrad Rzeszutek Wilk

BTW, are there any good materials on explaining _PSS, _PDC, _P.. and C-states

I only know of the specification itself, ...

Quoted 1 line

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

#4 lore raw
In reply to Konrad Rzeszutek Wilk
Quoted 8 lines

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.

Quoted 5 lines

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)

Quoted 4 lines

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

Quoted 143 lines

commit 498adade0091900564e6a6bf06a0f793f09d4764

Author: Konrad Rzeszutek Wilk <[email protected]>
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 <[email protected]>
drivers/acpi/processor_xen.c +1 -1
index 43760f8..db54525 100644
@@ -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
[email protected]
http://lists.xensource.com/xen-devel