Boris Derzhavets
2010-Apr-23 21:25 UTC
Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on F12 (serial log)
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. What you mean as a console log ? 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 Sorry to bother you too much. It''s not production, it''s development box and testing box. If i would not be on the bench in meantime, i would just replace board for ASUS P5Q3 and that''s it. Thank you. Boris. --- On Fri, 4/23/10, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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) To: "Boris Derzhavets" <bderzhavets@yahoo.com> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Marc - A. Dahlhaus [ Administration | Westermann GmbH ]" <mad@wol.de> Date: Friday, April 23, 2010, 4:16 PM On Fri, Apr 23, 2010 at 06:50:06AM -0700, Boris Derzhavets wrote:> Here it goes. > > Grub entry > > menuentry "Xen 4 / Ubuntu 9.10 kernel 2.6.32.10" { > insmod ext2 > set root=(hd1,1) > multiboot (hd1,1)/boot/xen.gz > module (hd1,1)/boot/vmlinuz-2.6.32.10 dummy=dummy root=/dev/sdb1 ro console=tty0 acpi.debug_level=0xffffffff acpi.debug_layer=0x2 initcall_debug > module (hd1,1)/boot/initrd-2.6.32.10.img > } >Where is the console output? Boris, you have to understand I can''t help you with debugging this out without some notion of what is going on. Please send me the console output (and do have the CONFIG_ACPI_DEBUG=y, CONFIG_ACPI_DEBUG_FUNC_TRACE=y set), or the motherboard. _______________________________________________ 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
Konrad Rzeszutek Wilk
2010-Apr-23 21:35 UTC
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=yThe kernel looks to have those config options built-in.? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yu, Ke
2010-Apr-24 02:09 UTC
RE: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on F12 (serial log)
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@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Saturday, April 24, 2010 5:36 AM
> To: Boris Derzhavets
> Cc: xen-devel@lists.xensource.com; 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@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Boris Derzhavets
2010-Apr-24 13:07 UTC
RE: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on F12 (serial log)
First dump obtained in previous message.
Second dump re-executed ( there was mistake at first run - 0x cff7e350 ):-
root@ServerLucid:~# acpidump --addr 0xcff7e350 --length 0x277 --binary --output
ssdt2.dat
root@ServerLucid:~# iasl -d ssdt2.dat
Intel ACPI Component Architecture
AML Disassembler version 20090521 [Jun 30 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 3.0a
Loading Acpi table from file ssdt2.dat
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
......................
Parsing completed
Disassembly completed, written to "ssdt2.dsl"
root@ServerLucid:~# cat ssdt2.dsl
/*
* Intel ACPI Component Architecture
* AML Disassembler version 20090521
*
* Disassembly of ssdt2.dat, Sat Apr 24 17:04:06 2010
*
*
* Original Table Header:
* Signature "SSDT"
* Length 0x00000277 (631)
* Revision 0x01
* Checksum 0x97
* OEM ID "DpgPmm"
* OEM Table ID "P002Ist"
* OEM Revision 0x00000012 (18)
* Compiler ID "INTL"
* Compiler Version 0x20060113 (537264403)
*/
DefinitionBlock ("ssdt2.aml", "SSDT", 1, "DpgPmm",
"P002Ist", 0x00000012)
{
External (NCPU)
External (NPCP, IntObj)
External (PDC1)
External (CFGD)
External (\_PR_.P002, DeviceObj)
Scope (\_PR.P002)
{
Method (_PPC, 0, NotSerialized)
{
Return (Zero)
}
Method (_PCT, 0, NotSerialized)
{
If (LAnd (LNot (And (CFGD, 0x4000)), LEqual (And (PDC1,
0x09), 0x09)))
{
Return (Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
}
Return (Package (0x02)
{
ResourceTemplate ()
{
Register (SystemIO,
0x10, // Bit Width
0x00, // Bit Offset
0x0000000000000900, // Address
,)
},
ResourceTemplate ()
{
Register (SystemIO,
0x10, // Bit Width
0x00, // Bit Offset
0x0000000000000902, // Address
,)
}
})
}
Method (_PSD, 0, NotSerialized)
{
Name (DOMN, 0x00)
Name (CRTP, 0x00)
Name (NOPR, 0x00)
If (And (PDC1, 0x0800))
{
Store (0xFE, CRTP)
}
Else
{
Store (0xFC, CRTP)
}
Divide (0x02, NPCP, Local1, Local2)
If (LEqual (Local1, 0x00))
{
Store (NPCP, Local1)
}
Decrement (Local1)
Store (Local1, DOMN)
Divide (NCPU, NPCP, Local2, Local3)
Store (Local3, NOPR)
Return (Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
DOMN,
CRTP,
NOPR
}
})
}
Method (_PSS, 0, NotSerialized)
{
If (LAnd (LNot (And (CFGD, 0x4000)), LEqual (And (PDC1,
0x09), 0x09)))
{
Return (NPSS)
}
Return (SPSS)
}
Name (SPSS, Package (0x04)
{
Package (0x06)
{
0x00000BB8,
0x00015BA8,
0x000000A0,
0x0000000A,
0x00000920,
0x00000920
},
Package (0x06)
{
0x00000A6B,
0x00013880,
0x000000A0,
0x0000000A,
0x0000081E,
0x0000081E
},
Package (0x06)
{
0x0000091D,
0x00011940,
0x000000A0,
0x0000000A,
0x0000071C,
0x0000071C
},
Package (0x06)
{
0x000007D0,
0x0000FDE8,
0x000000A0,
0x0000000A,
0x0000061A,
0x0000061A
}
})
Name (NPSS, Package (0x04)
{
Package (0x06)
{
0x00000BBB,
0x00015BA8,
0x0000000A,
0x0000000A,
0x00000920,
0x00000920
},
Package (0x06)
{
0x00000A6E,
0x00013880,
0x0000000A,
0x0000000A,
0x0000081E,
0x0000081E
},
Package (0x06)
{
0x00000920,
0x00011940,
0x0000000A,
0x0000000A,
0x0000071C,
0x0000071C
},
Package (0x06)
{
0x000007D3,
0x0000FDE8,
0x0000000A,
0x0000000A,
0x0000061A,
0x0000061A
}
})
}
}
--- On Fri, 4/23/10, Yu, Ke <ke.yu@intel.com> wrote:
From: Yu, Ke <ke.yu@intel.com>
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)
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Marc - A. Dahlhaus [ Administration
| Westermann GmbH ]" <mad@wol.de>
Date: Friday, April 23, 2010, 10:09 PM
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@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Saturday, April 24, 2010 5:36 AM
> To: Boris Derzhavets
> Cc: xen-devel@lists.xensource.com; 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@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
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
Yu, Ke
2010-Apr-26 09:32 UTC
RE: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on F12 (serial log)
Hi Boris,
Thanks for the info. Unluckily, the _PDC method is not in these two SSDT tables,
so let''s search more place for the _PDC method:
# acpidump > all.dat # dump all acpi binary data
# acpixtract all.dat # extract the DSDT, SSDT tables etc.
For each extracted table , please disassemble them:
# iasl -d xxxx.dat # e.g. iasl -d DSDT.dat
# grep "PDC" *.dsl #search _PDC in those disassemble files
If still no PDC is found, please search the "Load" command in those
*.dsl files, usually the Load command has the following form:
OperationRegion (XXXX, SystemMemory, <address>, <length>)
Load(XXXX, handle)
Where XXXX indicates memory block of [address , address+length], in which _PDS
is possibly in.
Then use acpidump to get those memory block:
# acpidump --addr <address> --length <length> --binary --output
xxxx.dat
# iasl -d xxxx.dat
# grep "PDC" *.dsl # again find the _PDC"
Once find the _PDC, please send out the *.dsl files.
Best Regards
Ke
-----Original Message-----
From: Boris Derzhavets [mailto:bderzhavets@yahoo.com]
Sent: Saturday, April 24, 2010 9:08 PM
To: Konrad Rzeszutek Wilk; Yu, Ke
Cc: xen-devel@lists.xensource.com; 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)
First dump obtained in previous message.
Second dump re-executed ( there was mistake at first run - 0x cff7e350 ):-
root@ServerLucid:~# acpidump --addr 0xcff7e350 --length 0x277 --binary --output
ssdt2.dat
root@ServerLucid:~# iasl -d ssdt2.dat
Intel ACPI Component Architecture
AML Disassembler version 20090521 [Jun 30 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 3.0a
Loading Acpi table from file ssdt2.dat
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
......................
Parsing completed
Disassembly completed, written to "ssdt2.dsl"
root@ServerLucid:~# cat ssdt2.dsl
/*
* Intel ACPI Component Architecture
* AML Disassembler version 20090521
*
* Disassembly of ssdt2.dat, Sat Apr 24 17:04:06 2010
*
*
* Original Table Header:
* Signature "SSDT"
* Length 0x00000277 (631)
* Revision 0x01
* Checksum 0x97
* OEM ID "DpgPmm"
* OEM Table ID "P002Ist"
* OEM Revision 0x00000012 (18)
* Compiler ID "INTL"
* Compiler Version 0x20060113 (537264403)
*/
DefinitionBlock ("ssdt2.aml", "SSDT", 1, "DpgPmm",
"P002Ist", 0x00000012)
{
External (NCPU)
External (NPCP, IntObj)
External (PDC1)
External (CFGD)
External (\_PR_.P002, DeviceObj)
Scope (\_PR.P002)
{
Method (_PPC, 0, NotSerialized)
{
Return (Zero)
}
Method (_PCT, 0, NotSerialized)
{
If (LAnd (LNot (And (CFGD, 0x4000)), LEqual (And (PDC1,
0x09), 0x09)))
{
Return (Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
}
Return (Package (0x02)
{
ResourceTemplate ()
{
Register (SystemIO,
0x10, // Bit Width
0x00, // Bit Offset
0x0000000000000900, // Address
,)
},
ResourceTemplate ()
{
Register (SystemIO,
0x10, // Bit Width
0x00, // Bit Offset
0x0000000000000902, // Address
,)
}
})
}
Method (_PSD, 0, NotSerialized)
{
Name (DOMN, 0x00)
Name (CRTP, 0x00)
Name (NOPR, 0x00)
If (And (PDC1, 0x0800))
{
Store (0xFE, CRTP)
}
Else
{
Store (0xFC, CRTP)
}
Divide (0x02, NPCP, Local1, Local2)
If (LEqual (Local1, 0x00))
{
Store (NPCP, Local1)
}
Decrement (Local1)
Store (Local1, DOMN)
Divide (NCPU, NPCP, Local2, Local3)
Store (Local3, NOPR)
Return (Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
DOMN,
CRTP,
NOPR
}
})
}
Method (_PSS, 0, NotSerialized)
{
If (LAnd (LNot (And (CFGD, 0x4000)), LEqual (And (PDC1,
0x09), 0x09)))
{
Return (NPSS)
}
Return (SPSS)
}
Name (SPSS, Package (0x04)
{
Package (0x06)
{
0x00000BB8,
0x00015BA8,
0x000000A0,
0x0000000A,
0x00000920,
0x00000920
},
Package (0x06)
{
0x00000A6B,
0x00013880,
0x000000A0,
0x0000000A,
0x0000081E,
0x0000081E
},
Package (0x06)
{
0x0000091D,
0x00011940,
0x000000A0,
0x0000000A,
0x0000071C,
0x0000071C
},
Package (0x06)
{
0x000007D0,
0x0000FDE8,
0x000000A0,
0x0000000A,
0x0000061A,
0x0000061A
}
})
Name (NPSS, Package (0x04)
{
Package (0x06)
{
0x00000BBB,
0x00015BA8,
0x0000000A,
0x0000000A,
0x00000920,
0x00000920
},
Package (0x06)
{
0x00000A6E,
0x00013880,
0x0000000A,
0x0000000A,
0x0000081E,
0x0000081E
},
Package (0x06)
{
0x00000920,
0x00011940,
0x0000000A,
0x0000000A,
0x0000071C,
0x0000071C
},
Package (0x06)
{
0x000007D3,
0x0000FDE8,
0x0000000A,
0x0000000A,
0x0000061A,
0x0000061A
}
})
}
}
--- On Fri, 4/23/10, Yu, Ke <ke.yu@intel.com> wrote:
From: Yu, Ke <ke.yu@intel.com>
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)
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Marc - A. Dahlhaus [ Administration
| Westermann GmbH ]" <mad@wol.de>
Date: Friday, April 23, 2010, 10:09 PM
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@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Saturday, April 24, 2010 5:36 AM
> To: Boris Derzhavets
> Cc: xen-devel@lists.xensource.com; 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@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
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
Boris Derzhavets
2010-Apr-26 10:44 UTC
RE: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on F12 (serial log)
root@ServerKoala:~/acpi# acpidump > all.dat
Wrong checksum for OEMB
Wrong checksum for OEMB!
That is for start.
Boris.
--- On Mon, 4/26/10, Yu, Ke <ke.yu@intel.com> wrote:
From: Yu, Ke <ke.yu@intel.com>
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)
To: "Boris Derzhavets" <bderzhavets@yahoo.com>, "Konrad
Rzeszutek Wilk" <konrad.wilk@oracle.com>
Cc: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Marc - A. Dahlhaus [ Administration
| Westermann GmbH ]" <mad@wol.de>
Date: Monday, April 26, 2010, 5:32 AM
Hi Boris,
Thanks for the info. Unluckily, the _PDC method is not in these two SSDT tables,
so let''s search more place for the _PDC method:
# acpidump > all.dat # dump all acpi binary data
# acpixtract all.dat # extract the DSDT, SSDT tables etc.
For each extracted table , please disassemble them:
# iasl -d xxxx.dat # e.g. iasl -d DSDT.dat
# grep "PDC" *.dsl #search _PDC in those disassemble files
If still no PDC is found, please search the "Load" command in those
*.dsl files, usually the Load command has the following form:
OperationRegion (XXXX, SystemMemory, <address>, <length>)
Load(XXXX, handle)
Where XXXX indicates memory block of [address , address+length], in which _PDS
is possibly in.
Then use acpidump to get those memory block:
# acpidump --addr <address> --length <length> --binary --output
xxxx.dat
# iasl -d xxxx.dat
# grep "PDC" *.dsl # again find the _PDC"
Once find the _PDC, please send out the *.dsl files.
Best Regards
Ke
-----Original Message-----
From: Boris Derzhavets [mailto:bderzhavets@yahoo.com]
Sent: Saturday, April 24, 2010 9:08 PM
To: Konrad Rzeszutek Wilk; Yu, Ke
Cc: xen-devel@lists.xensource.com; 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)
First dump obtained in previous message.
Second dump re-executed ( there was mistake at first run - 0x cff7e350 ):-
root@ServerLucid:~# acpidump --addr 0xcff7e350 --length 0x277 --binary --output
ssdt2.dat
root@ServerLucid:~# iasl -d ssdt2.dat
Intel ACPI Component Architecture
AML Disassembler version 20090521 [Jun 30 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 3.0a
Loading Acpi table from file ssdt2.dat
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
......................
Parsing completed
Disassembly completed, written to "ssdt2.dsl"
root@ServerLucid:~# cat ssdt2.dsl
/*
* Intel ACPI Component Architecture
* AML Disassembler version 20090521
*
* Disassembly of ssdt2.dat, Sat Apr 24 17:04:06 2010
*
*
* Original Table Header:
* Signature "SSDT"
* Length 0x00000277 (631)
* Revision 0x01
* Checksum 0x97
* OEM ID "DpgPmm"
* OEM Table ID "P002Ist"
* OEM Revision 0x00000012 (18)
* Compiler ID "INTL"
* Compiler Version 0x20060113 (537264403)
*/
DefinitionBlock ("ssdt2.aml", "SSDT", 1, "DpgPmm",
"P002Ist", 0x00000012)
{
External (NCPU)
External (NPCP, IntObj)
External (PDC1)
External (CFGD)
External (\_PR_.P002, DeviceObj)
Scope (\_PR.P002)
{
Method (_PPC, 0, NotSerialized)
{
Return (Zero)
}
Method (_PCT, 0, NotSerialized)
{
If (LAnd (LNot (And (CFGD, 0x4000)), LEqual (And (PDC1,
0x09), 0x09)))
{
Return (Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
}
Return (Package (0x02)
{
ResourceTemplate ()
{
Register (SystemIO,
0x10, // Bit Width
0x00, // Bit Offset
0x0000000000000900, // Address
,)
},
ResourceTemplate ()
{
Register (SystemIO,
0x10, // Bit Width
0x00, // Bit Offset
0x0000000000000902, // Address
,)
}
})
}
Method (_PSD, 0, NotSerialized)
{
Name (DOMN, 0x00)
Name (CRTP, 0x00)
Name (NOPR, 0x00)
If (And (PDC1, 0x0800))
{
Store (0xFE, CRTP)
}
Else
{
Store (0xFC, CRTP)
}
Divide (0x02, NPCP, Local1, Local2)
If (LEqual (Local1, 0x00))
{
Store (NPCP, Local1)
}
Decrement (Local1)
Store (Local1, DOMN)
Divide (NCPU, NPCP, Local2, Local3)
Store (Local3, NOPR)
Return (Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
DOMN,
CRTP,
NOPR
}
})
}
Method (_PSS, 0, NotSerialized)
{
If (LAnd (LNot (And (CFGD, 0x4000)), LEqual (And (PDC1,
0x09), 0x09)))
{
Return (NPSS)
}
Return (SPSS)
}
Name (SPSS, Package (0x04)
{
Package (0x06)
{
0x00000BB8,
0x00015BA8,
0x000000A0,
0x0000000A,
0x00000920,
0x00000920
},
Package (0x06)
{
0x00000A6B,
0x00013880,
0x000000A0,
0x0000000A,
0x0000081E,
0x0000081E
},
Package (0x06)
{
0x0000091D,
0x00011940,
0x000000A0,
0x0000000A,
0x0000071C,
0x0000071C
},
Package (0x06)
{
0x000007D0,
0x0000FDE8,
0x000000A0,
0x0000000A,
0x0000061A,
0x0000061A
}
})
Name (NPSS, Package (0x04)
{
Package (0x06)
{
0x00000BBB,
0x00015BA8,
0x0000000A,
0x0000000A,
0x00000920,
0x00000920
},
Package (0x06)
{
0x00000A6E,
0x00013880,
0x0000000A,
0x0000000A,
0x0000081E,
0x0000081E
},
Package (0x06)
{
0x00000920,
0x00011940,
0x0000000A,
0x0000000A,
0x0000071C,
0x0000071C
},
Package (0x06)
{
0x000007D3,
0x0000FDE8,
0x0000000A,
0x0000000A,
0x0000061A,
0x0000061A
}
})
}
}
--- On Fri, 4/23/10, Yu, Ke <ke.yu@intel.com> wrote:
From: Yu, Ke <ke.yu@intel.com>
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)
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Marc - A. Dahlhaus [ Administration
| Westermann GmbH ]" <mad@wol.de>
Date: Friday, April 23, 2010, 10:09 PM
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@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Saturday, April 24, 2010 5:36 AM
> To: Boris Derzhavets
> Cc: xen-devel@lists.xensource.com; 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@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
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