From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: acpidump crashes on some machines Date: Fri, 29 Jun 2012 21:48:25 -0400 Message-ID: <20120630014825.GA7003@phenom.dumpdata.com> References: <4FE1C423.6070001@amd.com> <20120620145127.GD12787@phenom.dumpdata.com> <4FE32DDA.10204@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <4FE32DDA.10204@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andre Przywara Cc: Jeremy Fitzhardinge , xen-devel , Jan Beulich List-Id: xen-devel@lists.xenproject.org > >>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] [] ? acpitest_init+0x5e/0x1000 > [testxenmap] > [ 351.964953] [] warn_slowpath_common+0x80/0x98 > [ 351.964956] [] ? 0xffffffffa0009fff > [ 351.964959] [] warn_slowpath_fmt+0x41/0x43 > [ 351.964963] [] acpitest_init+0x5e/0x1000 [testxenmap] > [ 351.964966] [] ? 0xffffffffa0009fff > [ 351.964971] [] do_one_initcall+0x7a/0x134 > [ 351.964976] [] sys_init_module+0xbf/0x24b > [ 351.964982] [] 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.