Re: acpidump crashes on some machines

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

> > [  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.