Re: acpidump crashes on some machines

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

> >>I tried to find something obvious, but to no avail. At least the new
> >>E820 looks sane, nothing that would prevent the mapping of the
> >>requested regions. Reverting this commit will not work easily on
> >>newer kernels, also is probably not desirable.
> >
> >The one thing that comes to my mind is the 1-1 mapping having
> >some issues. Can you boot the kernel with 'debug loglevel=8'. That should
> >print something like this:
> >
> >Setting pfn cfef0->cfef7 to 1-1
> >or such during bootup.
> 
> Hmm, I couldn't trigger such messages. Do I need some magic config
> to enable them? So far I have (among others):
> CONFIG_DEBUG_KERNEL=y
> CONFIG_DEBUG_VM=y
> CONFIG_DEBUG_VIRTUAL=y
> CONFIG_DEBUG_MEMORY_INIT=y

They should show up as part of the bootup process:

# dmesg | head
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.5.0-rc4upstream-00211-g9acc7bd (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Thu Jun 28 18:09:41 EDT 2012
[    0.000000] Command line: debug memblock=debug console=tty console=hvc0 earlyprintk=xen loglevel=10 initcall_debug xen-pciback.hide=(04:00.0)
[    0.000000] Disabled fast string operations
[    0.000000] Freeing 9a-100 pfn range: 102 pages freed
[    0.000000] 1-1 mapping on 9a->100
[    0.000000] Freeing 20000-20200 pfn range: 512 pages freed
[    0.000000] 1-1 mapping on 20000->20200
[    0.000000] 1-1 mapping on 40000->40200


> 
> >>
> >>But it does not show on every machine here, so the machine E820
> >>could actually be a differentiator. This particular box was a dual
> >>socket Barcelona server with 12GB of memory.
> >>
> >>This whole PV memory management goes beyond my knowledge, so I'd
> >>like to ask for help on this issue.
> >>If you need more information (I attached the boot log, which shows
> >>the two E820 tables), please ask. I can also quickly do some
> >>experiments if needed.
> >
> >This is strange one - the P2M code should fetch the MFN (so it should
> >give you cfef0) whenever anybody asks for that. Lets double-check that.
> >
> >Can you try this little module?
> 
> Right, it chokes. Mapping memory below 1MB works:
> # insmod testxenmap.ko pfn=0xf8
> # rmmod testxenmap
> # dmesg
> ...
> [   60.369526] va is 0xffff8800000f8000
> [   60.369533] acpi:00000000: 80 dc 0f 00 00 ff 00 00 00 00 00 00 00
> 00 00 00  ................
> [   60.369536] acpi:00000010: 52 53 44 20 50 54 52 20 4a 50 54 4c 54
> 44 20 02  RSD PTR JPTLTD .
> [   60.369538] acpi:00000020: 20 0f ef cf 24 00 00 00 64 0f ef cf 00
> 00 00 00   ...$...d.......
> ....
> you see the magic "RSD PTR " string here, at 0x20 the 32bit address
> of the actual tables (0xcfef0f20), which we try next:
> # insmod testxenmap.ko pfn=0xcfef0
> insmod: error inserting 'testxenmap.ko': -1 Invalid parameters
> # dmesg
> ....
> [  351.964914] ------------[ cut here ]------------
> [  351.964924] WARNING: at /src/linux-2.6/xentest/testxenmap.c:24
> acpitest_init+0x5e/0x1000 [testxenmap]()
> [  351.964926] Hardware name: empty
> [  351.964928] We get cfef0 instead of ffffffffffffffff!

Is cfef0 part of the 1-1 mapping and in ACPI? On my box I see this:

# dmesg | head -30 | grep bc55
[    0.000000] 1-1 mapping on bc558->bc5ac
[    0.000000] Xen: [mem 0x0000000040200000-0x00000000bc557fff] usable
[    0.000000] Xen: [mem 0x00000000bc558000-0x00000000bc560fff] ACPI data

So the E820 has it marked a ACPI data and sure enough I also see this:

[    0.000000] ACPI: DSDT 00000000bc558168 079E1 (v02 INTEL  DQ67SW   00000016 INTL 20051117)

Let me see what I get with the little module.

> [  351.964933] Modules linked in: testxenmap(O+) [last unloaded: testxenmap]
> [  351.964936] Pid: 4937, comm: insmod Tainted: G        W  O
> 3.5.0-rc3+ #106
> [  351.964938] Call Trace:
> [  351.964944]  [<ffffffffa000a05e>] ? acpitest_init+0x5e/0x1000
> [testxenmap]
> [  351.964953]  [<ffffffff81050747>] warn_slowpath_common+0x80/0x98
> [  351.964956]  [<ffffffffa000a000>] ? 0xffffffffa0009fff
> [  351.964959]  [<ffffffff810507f3>] warn_slowpath_fmt+0x41/0x43
> [  351.964963]  [<ffffffffa000a05e>] acpitest_init+0x5e/0x1000 [testxenmap]
> [  351.964966]  [<ffffffffa000a000>] ? 0xffffffffa0009fff
> [  351.964971]  [<ffffffff8100215a>] do_one_initcall+0x7a/0x134
> [  351.964976]  [<ffffffff81094512>] sys_init_module+0xbf/0x24b
> [  351.964982]  [<ffffffff816bb826>] cstar_dispatch+0x7/0x21
> [  351.964985] ---[ end trace 4eaa2a86a8e2da24 ]---
> [  351.964987] raw p2m (cfef0) gives us: ffffffffffffffff
> 
> starting the kernel without dom0_mem (where acpidump works
> flawlessly) also makes the module crash, although only at the point
> dumping the buffer (so this could be a different issue):


Yeah, that is b/c the pfn_to_mfn is trying to use an tree that woudl
not be initialized.