Xen project Mailing List

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@xxxxxxxxx]
Sent: Saturday, April 24, 2010 9:08 PM
To: Konrad Rzeszutek Wilk; Yu, Ke
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)

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@xxxxxxxxx> wrote:

From: Yu, Ke <ke.yu@xxxxxxxxx>
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@xxxxxxxxxx>, "Boris Derzhavets" <bderzhavets@xxxxxxxxx>
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Marc - A. Dahlhaus [ Administration | Westermann GmbH ]" <mad@xxxxxx>
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@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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel