[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] acpidump crashes on some machines
> >>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@xxxxxxxxxxxxxxxxxx) (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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel