It shows acpi_processor_set_pdc trying to access one BIOS memory or MMIO, but hypervisor fail to make the page mapping for this. But I still have no idea why this would happen.
When I try to find what the physical address is, I am a bit confused:
According to the src code
acpi_ex_system_memory_space_handler(u32 function,
acpi_physical_address address,
u32
bit_width,
acpi_integer * value,
void *handler_context, void *region_context)
and the asm code
000000000024be4e <acpi_ex_system_memory_space_handler>:
24be4e: 55 push %rbp
24be4f: 48 89 e5 mov %rsp,%rbp
24be52: 41 57 push %r15
24be54: 49 89 cf
mov %rcx,%r15
24be57: 41 56 push %r14
24be59: 41 89 d6 mov %edx,%r14d
24be5c: 41 55 push %r13
24be5e: 4d 89 cd mov %r9,%r13
24be61: 41 54 push %r12
24be63: 49 89 f4 mov %rsi,%r12
<------ R12 preserve RSI
24be66: 53 push %rbx
24be67: 48 83 ec 08 sub $0x8,%rsp
24be6b: 83 fa 10 cmp $0x10,%edx
the R12 preserve the RSI value, which is the second parameter "acpi_physical_address address". However, the log shows R12=ffffc900117e0000 and it is more like a virtual address rather than a physical address.
or is it possible my asm code is different from Boris?
BTW, Boris, could you please also dump the ACPI SSDT table by:
# acpidump --addr 0xcff7e0d0 --length 0x277 --binary --output ssdt1.dat
# iasl -d ssdt1.dat # will
generate ssdt1.asl
# acpidump --addr 0x cff7e350 --length 0x277 --binary --output ssdt2.dat
# iasl -d ssdt2.dat # will generate ssdt2.asl
And send out the ssdt1.asl and ssdt2.asl. in this case, we may be able to see which address the ACPI _PDC method want to access.
You can get iasl and acpidump from the following URL, in case you don't have it
acpidump:
http://kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20100416.tar.gz Iasl:
http://www.acpica.org/downloads/ Best Regards
Ke
> -----Original Message-----
> From:
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
>
bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Saturday, April 24, 2010 5:36 AM
> To: Boris Derzhavets
> Cc:
xen-devel@xxxxxxxxxxxxxxxxxxx; Marc - A. Dahlhaus [ Administration |
> Westermann GmbH ]
> Subject: Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10
> ( xen/stable) under Xen 4.0 on F12 (serial log)
>
> On Fri, Apr 23, 2010 at 02:25:04PM -0700, Boris Derzhavets wrote:
> > I've sent you dmesg output twice (as attachment) and it matches serial
> log trace log. It's attached to this message also. Serial log was sent to Yu Ke
> per
> > his request, that messade was cc'd to you and Jeremy as well.
>
> You
are right. I completly failed to see it. Thank you for sending it
> and sorry about the duplicate request.
> >
> > What you mean as a console log ?
>
> Serial log or anything that has a stack trace of the problem. The
> attachment you sent contains that, so that is good.
>
> The bug looks to be:
>
> calling acpi_processor_init+0x0/0x136 [processor] @ 812
> ACPI: SSDT 00000000cff7e0d0 00277 (v01 DpgPmm P001Ist 00000011
> INTL 20060113)
> ACPI: SSDT 00000000cff7e350 00277 (v01 DpgPmm P002Ist 00000012
> INTL 20060113)
> BUG: unable to handle kernel paging request at ffffc900117e0000
> IP: [<ffffffff81287f28>]
> acpi_ex_system_memory_space_handler+0x21e/0x2ba
> PGD 1f1887067 PUD 1f1888067 PMD 1e88e6067 PTE 0
> Oops: 0000 [#1]
SMP
> last sysfs file:
> /sys/devices/pci0000:00/0000:00:1e.0/0000:05:01.0/net/eth2/type
> CPU 1
> Modules linked in: processor(+) soundcore snd_page_alloc acpi_processor
> asus_atk0110 fuse skge r8169 mii floppy sky2 thermal
> Pid: 812, comm: modprobe Not tainted 2.6.32.10 #7 P5Q-E
> RIP: e030:[<ffffffff81287f28>] [<ffffffff81287f28>]
> acpi_ex_system_memory_space_handler+0x21e/0x2ba
> RSP: e02b:ffff8801dd34b858 EFLAGS: 00010246
> RAX: 00000000ffffffff RBX: ffff8801e43b2bc0 RCX: ffffffff81524e20
> RDX: ffffffff81524ef0 RSI: 00000000000000ca RDI: 0000000000000004
> RBP: ffff8801dd34b8b8 R08: 0000000000000080 R09: ffffffff816b88f3
> R10: ffffffff816bc098 R11: 0000000000000001 R12: ffffc900117e0000
> R13: ffff8801dd34b9b0 R14: 0000000000000000 R15: 0000000000000008
> FS: 00007f62694606f0(0000) GS:ffff880028055000(0000)
>
knlGS:0000000000000000
> CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: ffffc900117e0000 CR3: 00000001e57e8000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process modprobe (pid: 812, threadinfo ffff8801dd34a000, task
> ffff8801e1b74700)
> Stack:
> 0000000000000008 ffff880100000000 ffff880100000000
> ffff880180000000
> <0> 0000000000000000 0000000000000000 ffff8801dd34b8a8
> ffff8801e573a780
> <0> ffff8801e9ee8348 ffff8801e573a7c8 0000000000000000
> ffffffff81287d0a
> Call Trace:
> [<ffffffff81287d0a>] ? acpi_ex_system_memory_space_handler+0x0/0x2ba
> [<ffffffff8127b3bd>] acpi_ev_address_space_dispatch+0x272/0x2e1
> [<ffffffff81287d0a>] ?
acpi_ex_system_memory_space_handler+0x0/0x2ba
> [<ffffffff812807ac>] ? acpi_os_allocate+0x2a/0x2c
> [<ffffffff81280a00>] acpi_ex_load_op+0x140/0x4e8
> [<ffffffff81284d52>] acpi_ex_opcode_1A_1T_0R+0x5b/0xac
> [<ffffffff81275bc4>] acpi_ds_exec_end_op+0x138/0x64c
> [<ffffffff81296080>] acpi_ps_parse_loop+0xc6d/0xf49
> [<ffffffff81276ea4>] ? acpi_ds_call_control_method+0x339/0x34b
> [<ffffffff8129494c>] acpi_ps_parse_aml+0x167/0x483
> [<ffffffff8129facb>] ? acpi_ut_create_internal_object_dbg+0x10d/0x11c
> [<ffffffff81296dc2>] acpi_ps_execute_method+0x293/0x3dd
> [<ffffffff8129ba94>] ? acpi_ut_exit+0x36/0x3e
> [<ffffffff8128f8e6>] acpi_ns_evaluate+0x23a/0x3bb
> [<ffffffff8128ed37>] acpi_evaluate_object+0x1a7/0x309
>
[<ffffffff8102688c>] ? init_intel_pdc+0x11f/0x20c
> [<ffffffffa005e0e0>] acpi_processor_set_pdc+0x46/0x7e [processor]
> [<ffffffffa0063cc3>] xen_acpi_processor_add+0x376/0x4c5 [processor]
> [<ffffffff811722d4>] ? sysfs_do_create_link+0xe9/0x13e
> [<ffffffff8126a479>] acpi_device_probe+0x50/0x18a
> [<ffffffff8117234e>] ? sysfs_create_link+0x13/0x15
> [<ffffffff81360412>] driver_probe_device+0xdb/0x1fb
> [<ffffffff8136058f>] __driver_attach+0x5d/0x81
> [<ffffffff81360532>] ? __driver_attach+0x0/0x81
> [<ffffffff8135f8d3>] bus_for_each_dev+0x53/0x88
> [<ffffffff813601b1>] driver_attach+0x1e/0x20
> [<ffffffff8135fdfe>] bus_add_driver+0xd5/0x23b
> [<ffffffff8136087c>] driver_register+0x9d/0x10e
> [<ffffffffa006c000>] ?
acpi_processor_init+0x0/0x136 [processor]
> [<ffffffff8126b01c>] acpi_bus_register_driver+0x43/0x45
> [<ffffffffa0061b70>] xen_acpi_processor_init+0x15/0x17 [processor]
> [<ffffffffa006c0b2>] acpi_processor_init+0xb2/0x136 [processor]
> [<ffffffffa006c000>] ? acpi_processor_init+0x0/0x136 [processor]
> [<ffffffff8100a069>] do_one_initcall+0x5e/0x159
> [<ffffffff8108ec0b>] sys_init_module+0xd6/0x237
> [<ffffffff81012cf2>] system_call_fastpath+0x16/0x1b
> Code: 00 00 00 eb 48 41 83 ff 10 49 c7 45 00 00 00 00 00 74 1f 77 08 41 83
> ff 08 75 77 eb 0e 41 83 ff 20 74 16 41 83 ff 40 75 69 eb 18 <41> 0f b6 04 24
> eb 15 41 0f b7 04 24
> udev: renamed network interface eth1 to eth2
> eb 0e 45 8b 24 24 4d 89 65
> RIP [<ffffffff81287f28>]
>
acpi_ex_system_memory_space_handler+0x21e/0x2ba
> RSP <ffff8801dd34b858>
> CR2: ffffc900117e0000
> ---[ end trace 9f4c43facc7b61c1 ]---
>
> >
> > File ".config" of loaded 2.6.32.10 contained CONFIG_ACPI_DEBUG=y,
> > but i was unable to find
> > "CONFIG_ACPI_DEBUG_FUNC_TRACE not set".
> > Should i just add it :-
> > CONFIG_ACPI_DEBUG_FUNC_TRACE=y
>
> The kernel looks to have those config options built-in.?
>
>
> _______________________________________________
> Xen-devel mailing list
>
Xen-devel@xxxxxxxxxxxxxxxxxxx>
http://lists.xensource.com/xen-devel_______________________________________________
Xen-devel
mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxhttp://lists.xensource.com/xen-devel
Home