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 22:19:36 -0400 Message-ID: <20120630021936.GA27100@phenom.dumpdata.com> References: <4FE1C423.6070001@amd.com> <20120620145127.GD12787@phenom.dumpdata.com> <4FE32DDA.10204@amd.com> <20120630014825.GA7003@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20120630014825.GA7003@phenom.dumpdata.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 > > [ 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. So: [ 0.000000] 1-1 mapping on 9a->100 [ 0.000000] 1-1 mapping on 20000->20200 [ 0.000000] 1-1 mapping on 40000->40200 [ 0.000000] 1-1 mapping on bc558->bc5ac [ 0.000000] 1-1 mapping on bc5b4->bc8c5 [ 0.000000] 1-1 mapping on bc8c6->bcb7c [ 0.000000] 1-1 mapping on bcd00->100000 > dmesg | grep ACPI: | head [ 0.000000] ACPI: RSDP 00000000000f0450 00024 (v02 INTEL) [ 0.000000] ACPI: XSDT 00000000bc558070 00064 (v01 INTEL DQ67SW 01072009 AMI 00010013) [ 0.000000] ACPI: FACP 00000000bc55fb50 000F4 (v04 INTEL DQ67SW 01072009 AMI 00010013) [ 0.000000] ACPI: DSDT 00000000bc558168 079E1 (v02 INTEL DQ67SW 00000016 INTL 20051117) [ 0.000000] ACPI: FACS 00000000bc8dbf80 00040 [ 0.000000] ACPI: APIC 00000000bc55fc48 00072 (v03 INTEL DQ67SW 01072009 AMI 00010013) [ 0.000000] ACPI: TCPA 00000000bc55fcc0 00032 (v02 INTEL DQ67SW 00000001 MSFT 01000013) [ 0.000000] ACPI: SSDT 00000000bc55fcf8 00102 (v01 INTEL DQ67SW 00000001 MSFT 03000001) [ 0.000000] ACPI: MCFG 00000000bc55fe00 0003C (v01 INTEL DQ67SW 01072009 MSFT 00000097) [ 0.000000] ACPI: HPET 00000000bc55fe40 00038 (v01 INTEL DQ67SW 01072009 AMI. 00000004) 02:11:06 # 42 :~/ > rmmod acpidump;insmod /acpidump.ko pfn=0xbc55e 02:11:15 # 43 :~/ > rmmod acpidump;insmod /acpidump.ko pfn=0xbc559 02:11:26 # 44 :~/ > rmmod acpidump;insmod /acpidump.ko pfn=0xbc558 insmod: error inserting '/acpidump.ko': -1 Invalid parameters 2:16:37 # 8 :/data/ > insmod /acpidump.ko pfn=0xbc5ac insmod: error inserting '/acpidump.ko': -1 Invalid parameters 02:16:45 # 10 :/data/ > dmesg | grep p2m [ 389.847683] raw p2m (bc558) gives us: ffffffffffffffff [ 701.348502] raw p2m (bc5ac) gives us: ffffffffffffffff Huh? Looks like I can access the ACPI regions (bc559 had a bunch of stuff), but _not_ on the boundary PFNs. Plot thickens - but sadly I won't be able to do much until Thursday. I think the issue is somewhere in set_phys_range_identity. This loop: 767 for (pfn = pfn_s; pfn < pfn_e; pfn++) 768 if (!__set_phys_to_machine(pfn, IDENTITY_FRAME(pfn))) 769 break; 770 Probably needs pfn <= pfn_e. But that still does not explain why pfn_s is failing. Or maybe in the pfn_to_mfn machinary. It certainly has a lot of overrides in it. If you were to instrument any of those to print out more details on the offending PFNs that could help.