* acpidump crashes on some machines
@ 2012-06-20 12:37 Andre Przywara
2012-06-20 14:51 ` Konrad Rzeszutek Wilk
2012-07-04 10:21 ` David Vrabel
0 siblings, 2 replies; 14+ messages in thread
From: Andre Przywara @ 2012-06-20 12:37 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Jeremy Fitzhardinge, Jan Beulich; +Cc: xen-devel
[-- Attachment #1: Type: text/plain, Size: 5111 bytes --]
Hi,
we have some problems with acpidump running on Xen Dom0. On 64 bit Dom0
it will trigger the OOM killer, on 32 bit Dom0s it will cause a kernel
crash.
The hypervisor does not matter, I tried 4.1.3-rc2 as well as various
unstable versions including 25467, also 32-bit versions of 4.1.
The Dom0 kernels were always PVOPS versions, the problems starts with
3.2-rc1~194 and is still in 3.5.0-rc3.
Also you need to restrict the Dom0 memory with dom0_mem=
The crash says (on a 3.4.3 32bit Dom0 kernel):
uruk:~ # ./acpidump32
[ 158.843444] ------------[ cut here ]------------
[ 158.843460] kernel BUG at mm/rmap.c:1027!
[ 158.843466] invalid opcode: 0000 [#1] SMP
[ 158.843472] Modules linked in:
[ 158.843478]
[ 158.843483] Pid: 4874, comm: acpidump32 Tainted: G W 3.4.0+
#105 empty empty/S3993
[ 158.843493] EIP: 0061:[<c10b0e27>] EFLAGS: 00010246 CPU: 3
[ 158.843505] EIP is at __page_set_anon_rmap+0x12/0x45
[ 158.843511] EAX: d6022dc0 EBX: dfecb6e0 ECX: b76faf64 EDX: b76faf64
[ 158.843516] ESI: 00000000 EDI: b76faf64 EBP: d6091e8c ESP: d6091e84
[ 158.843522] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
[ 158.843529] CR0: 8005003b CR2: b76faf64 CR3: 17633000 CR4: 00000660
[ 158.843535] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 158.843581] DR6: ffff0ff0 DR7: 00000400
[ 158.843586] Process acpidump32 (pid: 4874, ti=d6090000 task=d60b34f0
task.ti=d6090000)
[ 158.843591] Stack:
[ 158.843594] dfecb6e0 00000001 d6091ea8 c10b15c4 00000000 d6022dc0
d61fbdd8 d6022dc0
[ 158.843610] 00000000 d6091efc c10aacbe 00000000 99948025 80000001
d8aa1f80 80000001
[ 158.843631] dfefc800 00000000 d8aa1f80 00000000 166b7025 d7f407d0
b76faf64 99948025
[ 158.843649] Call Trace:
[ 158.843656] [<c10b15c4>] do_page_add_anon_rmap+0x5b/0x64
[ 158.843664] [<c10aacbe>] handle_pte_fault+0x81d/0xa06
[ 158.843674] [<c10ab0ff>] handle_mm_fault+0x1fa/0x209
[ 158.843683] [<c159e4e8>] ? spurious_fault+0x104/0x104
[ 158.843688] [<c159e881>] do_page_fault+0x399/0x3b4
[ 158.843696] [<c10c639d>] ? filp_close+0x55/0x5f
[ 158.843701] [<c10c6408>] ? sys_close+0x61/0xa0
[ 158.843706] [<c159e4e8>] ? spurious_fault+0x104/0x104
[ 158.843714] [<c159c452>] error_code+0x5a/0x60
[ 158.843720] [<c159e4e8>] ? spurious_fault+0x104/0x104
[ 158.843724] Code: e8 45 91 00 00 89 c2 eb 09 2b 50 04 c1 ea 0c 03 50
4c 89 53 08 5b 5e 5d c3 55 89 e5 56 53 89 c3 89 d0 89 ca 8b 70 44 85 f6
75 02 <0f> 0b f6 43 04 01 75 27 83 7d 08 00 75 02 8b 36 46 89 73 04 f6
[ 158.843824] EIP: [<c10b0e27>] __page_set_anon_rmap+0x12/0x45 SS:ESP
0069:d6091e84
[ 158.843848] ---[ end trace 4eaa2a86a8e2da24 ]---
[ 158.843854] note: acpidump32[4874] exited with preempt_count 1
On 64bit the OOM goes around, finally killing the login shell:
uruk:~ # ./acpidump_inst
acpi_map_memory(917504, 131072);
opened /dev/mem (fd=3)
calling mmap(NULL, 131072, PROT_READ, MAP_PRIVATE, fd, e0000);
mmap returned 0xf7571000, function returns 0xf7571000
acpi_map_table(cfef0f64, "XSDT");
acpi_map_memory(3488550756, 36);
opened /dev/mem (fd=3)
calling mmap(NULL, 3976, PROT_READ, MAP_PRIVATE, fd, cfef0000);
mmap returned 0xf76fd000, function returns 0xf76fdf64
having mapped table header
reading signature:
Welcome to SUSE Linux Enterprise Server 11 SP1 (i586) - Kernel
3.5.0-rc3+ (hvc0).
uruk login:
-----------
This dump shows that the bug happens the moment acpidump accesses the
mmapped ACPI table at @cfef0000 (the lower map at e0000 works).
This is extra unfortunate as in SLES11 acpidump will be called by the
kbd init script (querying the BIOS NumLock setting!)
I bisected the Dom0 kernel to find this one (v3.2-rc~194):
commit 5eef150c1d7e41baaefd00dd56c153debcd86aee
Merge: 315eb8a f3f436e
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue Oct 25 09:17:07 2011 +0200
Merge branch 'stable/e820-3.2' of
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen
* 'stable/e820-3.2' of
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
xen: release all pages within 1-1 p2m mappings
xen: allow extra memory to be in multiple regions
xen: allow balloon driver to use more than one memory region
xen/balloon: simplify test for the end of usable RAM
xen/balloon: account for pages released during memory setup
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.
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.
Thanks a lot,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
[-- Attachment #2: uruk.bootlog --]
[-- Type: text/plain, Size: 44800 bytes --]
__ __ _ _ ____ _ _ _
\ \/ /___ _ __ | || | |___ \ _ _ _ __ ___| |_ __ _| |__ | | ___
\ // _ \ '_ \ | || |_ __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
/ \ __/ | | | |__ _| / __/|__| |_| | | | \__ \ || (_| | |_) | | __/
/_/\_\___|_| |_| |_|(_)_____| \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
(XEN) Xen version 4.2-unstable (aprzywar@osrc.amd.com) (gcc version 4.5.2 (GCC) ) Wed Jun 20 12:54:00 CEST 2012
(XEN) Latest ChangeSet: Thu Jun 07 19:46:57 2012 +0100 25467:32034d1914a6
(XEN) Bootloader: GNU GRUB 0.97-os.8
(XEN) Command line: console=com1 com1=115200 loglvl=all guest_loglvl=all noreboot dom0_mem=512M
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: none; EDID transfer time: 2 seconds
(XEN) EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN) Found 1 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000008ac00 (usable)
(XEN) 000000000008ac00 - 00000000000a0000 (reserved)
(XEN) 00000000000ce000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 00000000cfef0000 (usable)
(XEN) 00000000cfef0000 - 00000000cfef7000 (ACPI data)
(XEN) 00000000cfef7000 - 00000000cff03000 (ACPI NVS)
(XEN) 00000000cff03000 - 00000000d0000000 (reserved)
(XEN) 00000000fec00000 - 00000000fec03000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000fff80000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 0000000330000000 (usable)
(XEN) ACPI: RSDP 000F8010, 0024 (r2 PTLTD )
(XEN) ACPI: XSDT CFEF0F64, 0064 (r1 BRCM Anaheim 6040000 PTL 2000001)
(XEN) ACPI: FACP CFEF103C, 00F4 (r3 BRCM EXPLOSN 6040000 MSFT 2000001)
(XEN) ACPI Warning (tbfadt-0444): Optional field "Pm2ControlBlock" has zero address or length: 0000000000000000/C [20070126]
(XEN) ACPI: DSDT CFEF1130, 4777 (r2 AMD Anaheim 6040000 MSFT 2000002)
(XEN) ACPI: FACS CFF02FC0, 0040
(XEN) ACPI: TCPA CFEF58A7, 0032 (r1 BRCM Anaheim 6040000 PTL 20000001)
(XEN) ACPI: SRAT CFEF58D9, 0150 (r1 AMD HAMMER 6040000 AMD 1)
(XEN) ACPI: SSDT CFEF5A29, 143C (r1 AMD POWERNOW 6040000 AMD 1)
(XEN) ACPI: HPET CFEF6E65, 0038 (r1 BRCM Anaheim 6040000 BRCM 2000001)
(XEN) ACPI: SSDT CFEF6E9D, 0049 (r1 BRCM PRT0 6040000 BRCM 2000001)
(XEN) ACPI: SPCR CFEF6EE6, 0050 (r1 PTLTD $UCRTBL$ 6040000 PTL 1)
(XEN) ACPI: APIC CFEF6F36, 00CA (r1 BRCM Anaheim 6040000 PTL 2000001)
(XEN) System RAM: 12286MB (12581352kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 4 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 5 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 6 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 7 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 100000-d0000000
(XEN) SRAT: Node 0 PXM 0 100000000-1b0000000
(XEN) SRAT: Node 1 PXM 1 1b0000000-330000000
(XEN) NUMA: Allocated memnodemap from 32e92f000 - 32e933000
(XEN) NUMA: Using 8 for the hash shift.
(XEN) Domain heap initialised DMA width 30 bits
(XEN) found SMP MP-table at 000f8040
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x508
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[544,504], pm1x_evt[500,540]
(XEN) ACPI: wakeup_vec[cff02fcc], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
(XEN) Processor #1 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
(XEN) Processor #3 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
(XEN) Processor #4 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] enabled)
(XEN) Processor #5 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] enabled)
(XEN) Processor #6 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled)
(XEN) Processor #7 0:2 APIC version 16
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 17, address 0xfec00000, GSI 0-15
(XEN) ACPI: IOAPIC (id[0x09] address[0xfec01000] gsi_base[16])
(XEN) IOAPIC[1]: apic_id 9, version 17, address 0xfec01000, GSI 16-31
(XEN) ACPI: IOAPIC (id[0x0a] address[0xfec02000] gsi_base[32])
(XEN) IOAPIC[2]: apic_id 10, version 17, address 0xfec02000, GSI 32-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) Enabling APIC mode: Flat. Using 3 I/O APICs
(XEN) ACPI: HPET id: 0x1166a201 base: 0xfed00000
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 8 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 48 GSI, 1504 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2094.849 MHz processor.
(XEN) Initing memory sharing.
(XEN) AMD Fam10h machine check reporting enabled
(XEN) AMD-Vi: IOMMU not found!
(XEN) I/O virtualisation disabled
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 64 KiB.
(XEN) HVM: ASIDs enabled.
(XEN) SVM: Supported advanced features:
(XEN) - Nested Page Tables (NPT)
(XEN) - Last Branch Record (LBR) Virtualisation
(XEN) HVM: SVM enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) Brought up 8 CPUs
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) HPET: 3 timers (0 will be used for broadcast)
(XEN) ACPI sleep modes: S3
(XEN) MCA: Use hw thresholding to adjust polling frequency
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0xb54000
(XEN) elf_parse_binary: phdr: paddr=0x1c00000 memsz=0xab0e8
(XEN) elf_parse_binary: phdr: paddr=0x1cac000 memsz=0x12f00
(XEN) elf_parse_binary: phdr: paddr=0x1cbf000 memsz=0x5a4000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x2263000
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff81cbf210
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
(XEN) elf_xen_parse_note: PAE_MODE = "yes"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN) virt_base = 0xffffffff80000000
(XEN) elf_paddr_offset = 0x0
(XEN) virt_offset = 0xffffffff80000000
(XEN) virt_kstart = 0xffffffff81000000
(XEN) virt_kend = 0xffffffff82263000
(XEN) virt_entry = 0xffffffff81cbf210
(XEN) p2m_base = 0xffffffffffffffff
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2263000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 0000000320000000->0000000324000000 (114688 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff81000000->ffffffff82263000
(XEN) Init. ramdisk: ffffffff82263000->ffffffff82263000
(XEN) Phys-Mach map: ffffffff82263000->ffffffff82363000
(XEN) Start info: ffffffff82363000->ffffffff823634b4
(XEN) Page tables: ffffffff82364000->ffffffff82379000
(XEN) Boot stack: ffffffff82379000->ffffffff8237a000
(XEN) TOTAL: ffffffff80000000->ffffffff82400000
(XEN) ENTRY ADDRESS: ffffffff81cbf210
(XEN) Dom0 has maximum 8 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff81b54000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81c00000 -> 0xffffffff81cab0e8
(XEN) elf_load_binary: phdr 2 at 0xffffffff81cac000 -> 0xffffffff81cbef00
(XEN) elf_load_binary: phdr 3 at 0xffffffff81cbf000 -> 0xffffffff81d6b000
(XEN) Scrubbing Free RAM: ...................................................................................................................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 240kB init memory.
mapping kernel into physical memory
about to get started...
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.5.0-rc3+ (aprzywar@dosorca) (gcc version 4.5.2 (GCC) ) #103 SMP Mon Jun 18 14:11:37 CEST 2012
[ 0.000000] Command line: root=/dev/sda2 console=hvc0 earlyprintk=xen nomodeset
[ 0.000000] Freeing 8a-100 pfn range: 118 pages freed
[ 0.000000] Released 118 pages of unused memory
[ 0.000000] Set 196998 page(s) to 1-1 mapping
[ 0.000000] Populating 20000-20076 pfn range: 118 pages added
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] Xen: [mem 0x0000000000000000-0x0000000000089fff] usable
[ 0.000000] Xen: [mem 0x000000000008ac00-0x00000000000fffff] reserved
[ 0.000000] Xen: [mem 0x0000000000100000-0x00000000cfeeffff] usable
[ 0.000000] Xen: [mem 0x00000000cfef0000-0x00000000cfef6fff] ACPI data
[ 0.000000] Xen: [mem 0x00000000cfef7000-0x00000000cff02fff] ACPI NVS
[ 0.000000] Xen: [mem 0x00000000cff03000-0x00000000cfffffff] reserved
[ 0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec02fff] reserved
[ 0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[ 0.000000] Xen: [mem 0x00000000fff80000-0x00000000ffffffff] reserved
[ 0.000000] Xen: [mem 0x0000000100000000-0x0000000190621fff] usable
[ 0.000000] Xen: [mem 0x0000000190622000-0x000000032fffffff] unusable
[ 0.000000] bootconsole [xenboot0] enabled
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] DMI present.
[ 0.000000] No AGP bridge found
[ 0.000000] e820: last_pfn = 0x190622 max_arch_pfn = 0x400000000
[ 0.000000] e820: last_pfn = 0xcfef0 max_arch_pfn = 0x400000000
[ 0.000000] found SMP MP-table at [mem 0x000f8040-0x000f804f] mapped at [ffff8800000f8040]
[ 0.000000] init_memory_mapping: [mem 0x00000000-0xcfeeffff]
[ 0.000000] init_memory_mapping: [mem 0x100000000-0x190621fff]
[ 0.000000] ACPI: RSDP 00000000000f8010 00024 (v02 PTLTD )
[ 0.000000] ACPI: XSDT 00000000cfef0f64 00064 (v01 BRCM Anaheim 06040000 PTL 02000001)
[ 0.000000] ACPI: FACP 00000000cfef103c 000F4 (v03 BRCM EXPLOSN 06040000 MSFT 02000001)
[ 0.000000] ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x0000000000000000/0xC (20120320/tbfadt-579)
[ 0.000000] ACPI: DSDT 00000000cfef1130 04777 (v02 AMD Anaheim 06040000 MSFT 02000002)
[ 0.000000] ACPI: FACS 00000000cff02fc0 00040
[ 0.000000] ACPI: TCPA 00000000cfef58a7 00032 (v01 BRCM Anaheim 06040000 PTL 20000001)
[ 0.000000] ACPI: SRAT 00000000cfef58d9 00150 (v01 AMD HAMMER 06040000 AMD 00000001)
[ 0.000000] ACPI: SSDT 00000000cfef5a29 0143C (v01 AMD POWERNOW 06040000 AMD 00000001)
[ 0.000000] ACPI: HPET 00000000cfef6e65 00038 (v01 BRCM Anaheim 06040000 BRCM 02000001)
[ 0.000000] ACPI: SSDT 00000000cfef6e9d 00049 (v01 BRCM PRT0 06040000 BRCM 02000001)
[ 0.000000] ACPI: SPCR 00000000cfef6ee6 00050 (v01 PTLTD $UCRTBL$ 06040000 PTL 00000001)
[ 0.000000] ACPI: APIC 00000000cfef6f36 000CA (v01 BRCM Anaheim 06040000 PTL 02000001)
[ 0.000000] Scanning NUMA topology in Northbridge 24
[ 0.000000] Number of physical nodes 2
[ 0.000000] Node 0 MemBase 0000000000000000 Limit 0000000190622000
[ 0.000000] Node 1 bogus settings 1b0000000-190622000.
[ 0.000000] Initmem setup node 0 [mem 0x00000000-0x190621fff]
[ 0.000000] NODE_DATA [mem 0x20072000-0x20075fff]
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x00010000-0x00ffffff]
[ 0.000000] DMA32 [mem 0x01000000-0xffffffff]
[ 0.000000] Normal [mem 0x100000000-0x190621fff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x00010000-0x00089fff]
[ 0.000000] node 0: [mem 0x00100000-0xcfeeffff]
[ 0.000000] node 0: [mem 0x100000000-0x190621fff]
[ 0.000000] ACPI: PM-Timer IO Port: 0x508
[ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled)
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
[ 0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 8, version 17, address 0xfec00000, GSI 0-15
[ 0.000000] ACPI: IOAPIC (id[0x09] address[0xfec01000] gsi_base[16])
[ 0.000000] IOAPIC[1]: apic_id 9, version 17, address 0xfec01000, GSI 16-31
[ 0.000000] ACPI: IOAPIC (id[0x0a] address[0xfec02000] gsi_base[32])
[ 0.000000] IOAPIC[2]: apic_id 10, version 17, address 0xfec02000, GSI 32-47
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x1166a201 base: 0xfed00000
[ 0.000000] SMP: Allowing 8 CPUs, 0 hotplug CPUs
[ 0.000000] PM: Registered nosave memory: 000000000008a000 - 000000000008b000
[ 0.000000] PM: Registered nosave memory: 000000000008b000 - 0000000000100000
[ 0.000000] PM: Registered nosave memory: 00000000cfef0000 - 00000000cfef7000
[ 0.000000] PM: Registered nosave memory: 00000000cfef7000 - 00000000cff03000
[ 0.000000] PM: Registered nosave memory: 00000000cff03000 - 00000000d0000000
[ 0.000000] PM: Registered nosave memory: 00000000d0000000 - 00000000fec00000
[ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec03000
[ 0.000000] PM: Registered nosave memory: 00000000fec03000 - 00000000fee00000
[ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee01000
[ 0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000fff80000
[ 0.000000] PM: Registered nosave memory: 00000000fff80000 - 0000000100000000
[ 0.000000] e820: [mem 0xd0000000-0xfebfffff] available for PCI devices
[ 0.000000] Booting paravirtualized kernel on Xen
[ 0.000000] Xen version: 4.2-unstable (preserve-AD)
[ 0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:8 nr_node_ids:1
[ 0.000000] PERCPU: Embedded 26 pages/cpu @ffff88001fe00000 s77568 r8192 d20736 u262144
[ 6.478463] Built 1 zonelists in Node order, mobility grouping on. Total pages: 1415680
[ 6.478467] Policy zone: Normal
[ 6.478472] Kernel command line: root=/dev/sda2 console=hvc0 earlyprintk=xen nomodeset
[ 6.478607] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 6.478617] __ex_table already sorted, skipping sort
[ 6.566265] software IO TLB [mem 0x15400000-0x193fffff] (64MB) mapped at [ffff880015400000-ffff8800193fffff]
[ 6.569911] Memory: 337772k/6559880k available (6898k kernel code, 788056k absent, 5434052k reserved, 6070k data, 728k init)
[ 6.570040] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[ 6.570102] Hierarchical RCU implementation.
[ 6.570121] NR_IRQS:4352 nr_irqs:1152 16
[ 6.570235] xen: sci override: global_irq=9 trigger=0 polarity=1
[ 6.570273] xen: acpi sci 9
[ 6.580509] Console: colour VGA+ 80x25
[ 6.580517] console [hvc0] enabled, bootconsole disabled
[ 6.580517] console [hvc0] enabled, bootconsole disabled
[ 6.580578] installing Xen timer for CPU 0
[ 6.580617] Detected 2094.848 MHz processor.
[ 6.580630] Calibrating delay loop (skipped), value calculated using timer frequency.. 4189.69 BogoMIPS (lpj=8379392)
[ 6.580636] pid_max: default: 32768 minimum: 301
[ 6.580682] Security Framework initialized
[ 6.583355] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[ 6.589029] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 6.591229] Mount-cache hash table entries: 256
[ 6.591586] Initializing cgroup subsys cpuacct
[ 6.591593] Initializing cgroup subsys blkio
[ 6.591597] Initializing cgroup subsys perf_event
[ 6.591603] Initializing cgroup subsys net_prio
[ 6.591683] CPU: Physical Processor ID: 0
[ 6.591686] CPU: Processor Core ID: 0
[ 6.595474] ACPI: Core revision 20120320
[ 7.006297] cpu 0 spinlock event irq 65
[ 7.006332] Performance Events: AMD PMU driver.
[ 7.006337] ------------[ cut here ]------------
[ 7.006351] WARNING: at arch/x86/xen/enlighten.c:862 xen_apic_write+0x15/0x17()
[ 7.006355] Hardware name: empty
[ 7.006359] Modules linked in:
[ 7.006364] Pid: 1, comm: swapper/0 Not tainted 3.5.0-rc3+ #103
[ 7.006369] Call Trace:
[ 7.006379] [<ffffffff8105053b>] warn_slowpath_common+0x80/0x98
[ 7.006386] [<ffffffff81050568>] warn_slowpath_null+0x15/0x17
[ 7.006392] [<ffffffff81003411>] xen_apic_write+0x15/0x17
[ 7.006398] [<ffffffff81016dc2>] perf_events_lapic_init+0x2e/0x30
[ 7.006407] [<ffffffff81ccaaa2>] init_hw_perf_events+0x266/0x42a
[ 7.006415] [<ffffffff81008531>] ? xen_smp_intr_init+0x18c/0x263
[ 7.006420] [<ffffffff81cca83c>] ? check_bugs+0x2d/0x2d
[ 7.006426] [<ffffffff8100215a>] do_one_initcall+0x7a/0x134
[ 7.006434] [<ffffffff81cbfbe5>] kernel_init+0x9f/0x1d0
[ 7.006443] [<ffffffff816b9764>] kernel_thread_helper+0x4/0x10
[ 7.006450] [<ffffffff816b2e38>] ? retint_restore_args+0x5/0x6
[ 7.006456] [<ffffffff816b9760>] ? gs_change+0x13/0x13
[ 7.006469] ---[ end trace 4eaa2a86a8e2da22 ]---
[ 7.006474] ... version: 0
[ 7.006477] ... bit width: 48
[ 7.006480] ... generic registers: 4
[ 7.006483] ... value mask: 0000ffffffffffff
[ 7.006486] ... max period: 00007fffffffffff
[ 7.006489] ... fixed-purpose events: 0
[ 7.006492] ... event mask: 000000000000000f
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[ 7.007193] MCE: In-kernel MCE decoding enabled.
[ 7.007328] installing Xen timer for CPU 1
[ 7.007347] cpu 1 spinlock event irq 72
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[ 7.007721] installing Xen timer for CPU 2
[ 7.007735] cpu 2 spinlock event irq 79
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[ 7.008028] installing Xen timer for CPU 3
[ 7.008042] cpu 3 spinlock event irq 86
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[ 7.008337] installing Xen timer for CPU 4
[ 7.008352] cpu 4 spinlock event irq 93
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[ 7.008676] installing Xen timer for CPU 5
[ 7.008691] cpu 5 spinlock event irq 100
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[ 7.009028] installing Xen timer for CPU 6
[ 7.009042] cpu 6 spinlock event irq 107
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[ 7.009388] installing Xen timer for CPU 7
[ 7.009402] cpu 7 spinlock event irq 114
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[ 7.009672] Brought up 8 CPUs
[ 7.010659] EVM: security.capability
[ 7.010790] PM: Registering ACPI NVS region [mem 0xcfef7000-0xcff02fff] (49152 bytes)
[ 7.010840] xor: automatically using best checksumming function:
[ 7.050872] generic_sse: 2684.000 MB/sec
[ 7.050896] Grant tables using version 2 layout.
[ 7.050917] Grant table initialized
[ 7.050980] RTC time: 10:49:10, date: 06/20/12
[ 7.051038] NET: Registered protocol family 16
[ 7.052288] TOM: 00000000d0000000 aka 3328M
[ 7.052319] TOM2: 0000000330000000 aka 13056M
[ 7.052605] ACPI: bus type pci registered
[ 7.052814] PCI: Using configuration type 1 for base access
[ 7.052819] PCI: Using configuration type 1 for extended access
[ 7.075903] bio: create slab <bio-0> at 0
[ 7.144028] raid6: sse2x1 2320 MB/s
[ 7.212782] raid6: sse2x2 3292 MB/s
[ 7.281490] raid6: sse2x4 3456 MB/s
[ 7.281494] raid6: using algorithm sse2x4 (3456 MB/s)
[ 7.281498] raid6: using intx1 recovery algorithm
[ 7.281603] ACPI: Added _OSI(Module Device)
[ 7.281608] ACPI: Added _OSI(Processor Device)
[ 7.281611] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 7.281615] ACPI: Added _OSI(Processor Aggregator Device)
[ 7.288311] ACPI: Interpreter enabled
[ 7.288332] ACPI: (supports S0 S1 S5)
[ 7.288338] ACPI: Using IOAPIC for interrupt routing
[ 7.302182] ACPI: No dock devices found.
[ 7.302191] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 7.303385] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f])
[ 7.304756] pci_root PNP0A08:00: host bridge window [io 0x0000-0x03af]
[ 7.304762] pci_root PNP0A08:00: host bridge window [io 0x03e0-0x0fff]
[ 7.304768] pci_root PNP0A08:00: host bridge window [io 0x03b0-0x03df]
[ 7.304773] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff]
[ 7.304779] pci_root PNP0A08:00: host bridge window [io 0x1000-0x6fff]
[ 7.304784] pci_root PNP0A08:00: host bridge window [io 0x7000-0xffff]
[ 7.304789] pci_root PNP0A08:00: host bridge window [mem 0xfec00000-0xfecfffff]
[ 7.304795] pci_root PNP0A08:00: host bridge window [mem 0xe8000000-0xefffffff]
[ 7.304800] pci_root PNP0A08:00: host bridge window [mem 0xd8000000-0xd84fffff]
[ 7.304806] pci_root PNP0A08:00: host bridge window [mem 0xd0000000-0xd7ffffff]
[ 7.304811] pci_root PNP0A08:00: host bridge window [mem 0xfe000000-0xfebfffff]
[ 7.304817] pci_root PNP0A08:00: host bridge window [mem 0xfec04000-0xfecfffff]
[ 7.304822] pci_root PNP0A08:00: host bridge window [mem 0xfed00400-0xfed07fff]
[ 7.304828] pci_root PNP0A08:00: host bridge window [mem 0xfed08008-0xfedfffff]
[ 7.304834] pci_root PNP0A08:00: host bridge window [mem 0xfee01000-0xffffffff]
[ 7.304841] pci_root PNP0A08:00: host bridge window expanded to [mem 0xfec00000-0xfecfffff]; [mem 0xfec04000-0xfecfffff] ignored
[ 7.304955] PCI host bridge to bus 0000:00
[ 7.304961] pci_bus 0000:00: root bus resource [io 0x0000-0x03af]
[ 7.304966] pci_bus 0000:00: root bus resource [io 0x03e0-0x0fff]
[ 7.304972] pci_bus 0000:00: root bus resource [io 0x03b0-0x03df]
[ 7.304977] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[ 7.304982] pci_bus 0000:00: root bus resource [io 0x1000-0x6fff]
[ 7.304987] pci_bus 0000:00: root bus resource [io 0x7000-0xffff]
[ 7.304992] pci_bus 0000:00: root bus resource [mem 0xfec00000-0xfecfffff]
[ 7.304998] pci_bus 0000:00: root bus resource [mem 0xe8000000-0xefffffff]
[ 7.305003] pci_bus 0000:00: root bus resource [mem 0xd8000000-0xd84fffff]
[ 7.305008] pci_bus 0000:00: root bus resource [mem 0xd0000000-0xd7ffffff]
[ 7.305014] pci_bus 0000:00: root bus resource [mem 0xfe000000-0xfebfffff]
[ 7.305019] pci_bus 0000:00: root bus resource [mem 0xfed00400-0xfed07fff]
[ 7.305024] pci_bus 0000:00: root bus resource [mem 0xfed08008-0xfedfffff]
[ 7.305030] pci_bus 0000:00: root bus resource [mem 0xfee01000-0xffffffff]
[ 7.305214] pci 0000:00:01.0: Enabling HT MSI Mapping
[ 7.310204] pci 0000:00:01.0: PCI bridge to [bus 01-02]
[ 7.310330] pci 0000:01:0d.0: PCI bridge to [bus 02-02]
[ 7.310494] pci 0000:00:06.0: PCI bridge to [bus 03-03]
[ 7.310611] pci 0000:00:07.0: PCI bridge to [bus 04-04]
[ 7.310728] pci 0000:00:08.0: PCI bridge to [bus 05-05]
[ 7.310845] pci 0000:00:09.0: PCI bridge to [bus 06-06]
[ 7.311203] pci 0000:07:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
[ 7.311225] pci 0000:00:0a.0: PCI bridge to [bus 07-08]
[ 7.311961] pci 0000:07:00.0: PCI bridge to [bus 08-08]
[ 7.312601] pci0000:00: Requesting ACPI _OSC control (0x1d)
[ 7.312608] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d
[ 7.312613] ACPI _OSC control for PCIe not granted, disabling ASPM
(XEN) PCI add device 0000:00:01.0
(XEN) PCI add device 0000:00:02.0
(XEN) PCI add device 0000:00:02.1
(XEN) PCI add device 0000:00:02.2
(XEN) PCI add device 0000:00:03.0
(XEN) PCI add device 0000:00:03.1
(XEN) PCI add device 0000:00:03.2
(XEN) PCI add device 0000:00:04.0
(XEN) PCI add device 0000:00:06.0
(XEN) PCI add device 0000:00:07.0
(XEN) PCI add device 0000:00:08.0
(XEN) PCI add device 0000:00:09.0
(XEN) PCI add device 0000:00:0a.0
(XEN) PCI add device 0000:00:18.0
(XEN) PCI add device 0000:00:18.1
(XEN) PCI add device 0000:00:18.2
(XEN) PCI add device 0000:00:18.3
(XEN) PCI add device 0000:00:18.4
(XEN) PCI add device 0000:00:19.0
(XEN) PCI add device 0000:00:19.1
(XEN) PCI add device 0000:00:19.2
(XEN) PCI add device 0000:00:19.3
(XEN) PCI add device 0000:00:19.4
(XEN) PCI add device 0000:01:0d.0
(XEN) PCI add device 0000:01:0e.0
(XEN) PCI add device 0000:01:0e.1
(XEN) PCI add device 0000:07:00.0
(XEN) PCI add device 0000:08:04.0
(XEN) PCI add device 0000:08:04.1
[ 7.320699] ACPI: PCI Interrupt Link [LNKU] (IRQs *10 11)
[ 7.320751] ACPI: PCI Interrupt Link [LNKW] (IRQs 10 11) *0, disabled.
[ 7.320824] ACPI: PCI Interrupt Link [LNKS] (IRQs 5 *7 11)
[ 7.320938] ACPI: PCI Interrupt Link [LN00] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.320984] ACPI: PCI Interrupt Link [LN01] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321049] ACPI: PCI Interrupt Link [LN02] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321098] ACPI: PCI Interrupt Link [LN03] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321158] ACPI: PCI Interrupt Link [LN04] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321218] ACPI: PCI Interrupt Link [LN05] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321268] ACPI: PCI Interrupt Link [LN06] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321317] ACPI: PCI Interrupt Link [LN07] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321370] ACPI: PCI Interrupt Link [LN08] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321432] ACPI: PCI Interrupt Link [LN09] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321488] ACPI: PCI Interrupt Link [LN0A] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321548] ACPI: PCI Interrupt Link [LN0B] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321610] ACPI: PCI Interrupt Link [LN0C] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321666] ACPI: PCI Interrupt Link [LN0D] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321709] ACPI: PCI Interrupt Link [LN0E] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321779] ACPI: PCI Interrupt Link [LN0F] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321844] ACPI: PCI Interrupt Link [LN10] (IRQs 3 4 5 7 *11 12 14 15)
[ 7.321908] ACPI: PCI Interrupt Link [LN11] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.321963] ACPI: PCI Interrupt Link [LN12] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.322018] ACPI: PCI Interrupt Link [LN13] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.322100] ACPI: PCI Interrupt Link [LN14] (IRQs 3 4 *5 7 11 12 14 15)
[ 7.322153] ACPI: PCI Interrupt Link [LN15] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.322208] ACPI: PCI Interrupt Link [LN16] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.322306] ACPI: PCI Interrupt Link [LN17] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.322383] ACPI: PCI Interrupt Link [LN18] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.322423] ACPI: PCI Interrupt Link [LN19] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.322487] ACPI: PCI Interrupt Link [LN1A] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.322565] ACPI: PCI Interrupt Link [LN1B] (IRQs 3 4 *5 7 11 12 14 15)
[ 7.322616] ACPI: PCI Interrupt Link [LN1C] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.322664] ACPI: PCI Interrupt Link [LN1D] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.322732] ACPI: PCI Interrupt Link [LN1E] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.322779] ACPI: PCI Interrupt Link [LN1F] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[ 7.322957] xen/balloon: Initialising balloon driver.
[ 7.366475] xen-balloon: Initialising balloon driver.
[ 7.366941] vgaarb: device added: PCI:0000:00:04.0,decodes=io+mem,owns=io+mem,locks=none
[ 7.366966] vgaarb: loaded
[ 7.366969] vgaarb: bridge control possible 0000:00:04.0
[ 7.367272] SCSI subsystem initialized
[ 7.367777] ACPI: bus type usb registered
[ 7.367949] usbcore: registered new interface driver usbfs
[ 7.368037] usbcore: registered new interface driver hub
[ 7.368160] usbcore: registered new device driver usb
[ 7.368734] Advanced Linux Sound Architecture Driver Version 1.0.25.
[ 7.368740] PCI: Using ACPI for IRQ routing
[ 7.369374] NetLabel: Initializing
[ 7.369378] NetLabel: domain hash size = 128
[ 7.369382] NetLabel: protocols = UNLABELED CIPSOv4
[ 7.369444] NetLabel: unlabeled traffic allowed by default
[ 7.369626] Switching to clocksource xen
[ 7.369827] pnp: PnP ACPI init
[ 7.369841] ACPI: bus type pnp registered
[ 7.370049] system 00:00: [mem 0xfed08000-0xfed08007] has been reserved
[ 7.370828] system 00:01: [mem 0xe0000000-0xefffffff] could not be reserved
[ 7.373707] system 00:0b: [io 0x040b] has been reserved
[ 7.373713] system 00:0b: [io 0x04d0-0x04d1] has been reserved
[ 7.373720] system 00:0b: [io 0x04d6] has been reserved
[ 7.373725] system 00:0b: [io 0x0500-0x0560] has been reserved
[ 7.373730] system 00:0b: [io 0x0558-0x055b] has been reserved
[ 7.373736] system 00:0b: [io 0x0580-0x058f] has been reserved
[ 7.373741] system 00:0b: [io 0x0590-0x0593] has been reserved
[ 7.373746] system 00:0b: [io 0x0600-0x061f] has been reserved
[ 7.373751] system 00:0b: [io 0x0620-0x0623] has been reserved
[ 7.373759] system 00:0b: [io 0x0700-0x0703] has been reserved
[ 7.373767] system 00:0b: [io 0x0c00-0x0c01] has been reserved
[ 7.373772] system 00:0b: [io 0x0c06-0x0c08] has been reserved
[ 7.373777] system 00:0b: [io 0x0c14] has been reserved
[ 7.373782] system 00:0b: [io 0x0c49-0x0c4a] has been reserved
[ 7.373787] system 00:0b: [io 0x0c50-0x0c53] has been reserved
[ 7.373792] system 00:0b: [io 0x0c6c] has been reserved
[ 7.373797] system 00:0b: [io 0x0c6f] has been reserved
[ 7.373802] system 00:0b: [io 0x0cd6-0x0cd7] has been reserved
[ 7.373807] system 00:0b: [io 0x0cf9] could not be reserved
[ 7.373813] system 00:0b: [io 0x0f50-0x0f58] has been reserved
[ 7.373966] Already setup the GSI :4
[ 7.375025] pnp: PnP ACPI: found 16 devices
[ 7.375029] ACPI: ACPI bus type pnp unregistered
[ 7.386348] PM-Timer failed consistency check (0x0xffffff) - aborting.
[ 7.386597] pci 0000:00:01.0: BAR 15: assigned [mem 0xe8000000-0xe80fffff pref]
[ 7.386605] pci 0000:00:04.0: BAR 6: assigned [mem 0xfec20000-0xfec3ffff pref]
[ 7.386615] pci 0000:01:0e.0: BAR 6: assigned [mem 0xe8000000-0xe801ffff pref]
[ 7.386621] pci 0000:01:0d.0: PCI bridge to [bus 02-02]
[ 7.386641] pci 0000:00:01.0: PCI bridge to [bus 01-02]
[ 7.386647] pci 0000:00:01.0: bridge window [io 0x6000-0x6fff]
[ 7.386657] pci 0000:00:01.0: bridge window [mem 0xd8100000-0xd81fffff]
[ 7.386671] pci 0000:00:01.0: bridge window [mem 0xe8000000-0xe80fffff pref]
[ 7.386694] pci 0000:00:06.0: PCI bridge to [bus 03-03]
[ 7.386723] pci 0000:00:07.0: PCI bridge to [bus 04-04]
[ 7.386765] pci 0000:00:08.0: PCI bridge to [bus 05-05]
[ 7.386809] pci 0000:00:09.0: PCI bridge to [bus 06-06]
[ 7.386838] pci 0000:07:00.0: PCI bridge to [bus 08-08]
[ 7.386854] pci 0000:07:00.0: bridge window [mem 0xd8000000-0xd80fffff]
[ 7.386902] pci 0000:00:0a.0: PCI bridge to [bus 07-08]
[ 7.386918] pci 0000:00:0a.0: bridge window [mem 0xd8000000-0xd80fffff]
[ 7.387036] Already setup the GSI :32
[ 7.387056] Already setup the GSI :32
[ 7.387066] Already setup the GSI :32
[ 7.387077] Already setup the GSI :32
[ 7.387185] NET: Registered protocol family 2
[ 7.387503] IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
[ 7.389348] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[ 7.391853] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[ 7.392402] TCP: Hash tables configured (established 262144 bind 65536)
[ 7.392409] TCP: reno registered
[ 7.392508] UDP hash table entries: 4096 (order: 5, 131072 bytes)
[ 7.392632] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
[ 7.392849] NET: Registered protocol family 1
[ 7.393089] RPC: Registered named UNIX socket transport module.
[ 7.393096] RPC: Registered udp transport module.
[ 7.393105] RPC: Registered tcp transport module.
[ 7.393108] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 7.393302] pci 0000:00:02.0: disabled boot interrupts on device [1166:0205]
[ 7.393480] ACPI: PCI Interrupt Link [LNKU] enabled at IRQ 10
[ 7.445860] Already setup the GSI :10
[ 7.501776] Already setup the GSI :10
[ 7.504275] microcode: CPU0: patch_level=0x01000065
[ 7.504286] microcode: CPU1: patch_level=0x01000065
[ 7.504306] microcode: CPU2: patch_level=0x01000065
[ 7.504330] microcode: CPU3: patch_level=0x01000065
[ 7.504355] microcode: CPU4: patch_level=0x01000065
[ 7.504377] microcode: CPU5: patch_level=0x01000065
[ 7.504403] microcode: CPU6: patch_level=0x01000065
[ 7.504430] microcode: CPU7: patch_level=0x01000065
[ 7.504530] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[ 7.506353] sha1_ssse3: Neither AVX nor SSSE3 is available/usable.
[ 7.506880] audit: initializing netlink socket (disabled)
[ 7.506913] type=2000 audit(1340189350.092:1): initialized
[ 7.540089] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[ 7.546507] VFS: Disk quotas dquot_6.5.2
[ 7.546632] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 7.548235] NFS: Registering the id_resolver key type
[ 7.548256] Key type id_resolver registered
[ 7.548934] fuse init (API version 7.19)
[ 7.549329] msgmni has been set to 659
[ 7.551203] NET: Registered protocol family 38
[ 7.551391] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[ 7.551398] io scheduler noop registered
[ 7.551402] io scheduler deadline registered
[ 7.551601] io scheduler cfq registered (default)
[ 7.553669] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0C:00/input/input0
[ 7.553679] ACPI: Power Button [PWRB]
[ 7.553888] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[ 7.553894] ACPI: Power Button [PWRF]
[ 7.554059] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input2
[ 7.554065] ACPI: Sleep Button [SLPF]
[ 7.560418] Event-channel device installed.
[ 7.561677] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
(XEN) Cannot bind IRQ4 to dom0. In use by 'ns16550'.
(XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'.
(XEN) Cannot bind IRQ4 to dom0. In use by 'ns16550'.
(XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'.
(XEN) Cannot bind IRQ4 to dom0. In use by 'ns16550'.
(XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'.
(XEN) Cannot bind IRQ4 to dom0. In use by 'ns16550'.
(XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'.
[ 7.837905] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 7.859709] 00:0d: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 7.860308] hpet_acpi_add: no address or irqs in _CRS
[ 7.860512] Non-volatile memory driver v1.3
[ 7.860592] Linux agpgart interface v0.103
[ 7.863161] [drm] Initialized drm 1.1.0 20060810
[ 7.863167] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module!
[ 7.866674] brd: module loaded
[ 7.868524] loop: module loaded
[ 7.869066] nbd: registered device at major 43
[ 7.872550] Loading iSCSI transport class v2.0-870.
[ 7.874722] ACPI: PCI Interrupt Link [LNKS] enabled at IRQ 11
[ 7.876203] scsi0 : sata_svw
[ 7.876467] scsi1 : sata_svw
[ 7.876699] scsi2 : sata_svw
[ 7.876971] scsi3 : sata_svw
[ 7.877156] ata1: SATA max UDMA/133 mmio m8192@0xd8100000 port 0xd8100000 irq 11
[ 7.877162] ata2: SATA max UDMA/133 mmio m8192@0xd8100000 port 0xd8100100 irq 11
[ 7.877168] ata3: SATA max UDMA/133 mmio m8192@0xd8100000 port 0xd8100200 irq 11
[ 7.877177] ata4: SATA max UDMA/133 mmio m8192@0xd8100000 port 0xd8100300 irq 11
[ 7.877346] Already setup the GSI :11
[ 7.879305] scsi4 : pata_serverworks
[ 7.879539] scsi5 : pata_serverworks
[ 7.879885] ata5: PATA max UDMA/66 cmd 0x1f0 ctl 0x3f6 bmdma 0x4800 irq 14
[ 7.879894] ata6: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0x4808 irq 15
[ 7.882842] tun: Universal TUN/TAP device driver, 1.6
[ 7.882848] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 7.883212] pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
[ 7.883464] cnic: Broadcom NetXtreme II CNIC Driver cnic v2.5.10 (March 21, 2012)
[ 7.883609] tg3.c:v3.123 (March 21, 2012)
[ 7.943267] tg3 0000:08:04.0: eth0: Tigon3 [partno(BCM95715) rev 9003] (PCIX:133MHz:64-bit) MAC address 00:e0:81:80:1d:9c
[ 7.943281] tg3 0000:08:04.0: eth0: attached PHY is 5714 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[ 7.943288] tg3 0000:08:04.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[ 7.943294] tg3 0000:08:04.0: eth0: dma_rwctrl[76148000] dma_mask[40-bit]
[ 7.943487] Already setup the GSI :36
[ 7.988541] tg3 0000:08:04.1: eth1: Tigon3 [partno(BCM95715) rev 9003] (PCIX:133MHz:64-bit) MAC address 00:e0:81:80:1d:9d
[ 7.988550] tg3 0000:08:04.1: eth1: attached PHY is 5714 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[ 7.988557] tg3 0000:08:04.1: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[ 7.988563] tg3 0000:08:04.1: eth1: dma_rwctrl[76148000] dma_mask[40-bit]
[ 7.988733] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
[ 7.988738] e100: Copyright(c) 1999-2006 Intel Corporation
[ 7.988835] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
[ 7.988840] e1000: Copyright (c) 1999-2006 Intel Corporation.
[ 7.988938] e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
[ 7.988942] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
[ 7.989044] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.6.0-k
[ 7.989049] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation.
[ 7.989136] sky2: driver version 1.30
[ 7.989683] Initialising Xen virtual ethernet driver.
[ 7.989761] Fusion MPT base driver 3.04.20
[ 7.989765] Copyright (c) 1999-2008 LSI Corporation
[ 7.989781] Fusion MPT SAS Host driver 3.04.20
[ 7.989881] Fusion MPT misc device (ioctl) driver 3.04.20
[ 7.989970] mptctl: Registered with Fusion MPT base driver
[ 7.989974] mptctl: /dev/mptctl @ (major,minor=10,220)
[ 7.990251] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 7.990437] Already setup the GSI :10
[ 7.990466] ehci_hcd 0000:00:03.2: EHCI Host Controller
[ 7.990645] ehci_hcd 0000:00:03.2: new USB bus registered, assigned bus number 1
[ 8.017764] ehci_hcd 0000:00:03.2: irq 10, io mem 0xd8412000
[ 8.029737] ehci_hcd 0000:00:03.2: USB 2.0 started, EHCI 1.00
[ 8.029789] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 8.029798] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 8.029803] usb usb1: Product: EHCI Host Controller
[ 8.029808] usb usb1: Manufacturer: Linux 3.5.0-rc3+ ehci_hcd
[ 8.029812] usb usb1: SerialNumber: 0000:00:03.2
[ 8.030088] hub 1-0:1.0: USB hub found
[ 8.030096] hub 1-0:1.0: 4 ports detected
[ 8.030321] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 8.030500] Already setup the GSI :10
[ 8.030527] ohci_hcd 0000:00:03.0: OHCI Host Controller
[ 8.030641] ohci_hcd 0000:00:03.0: new USB bus registered, assigned bus number 2
[ 8.030684] ohci_hcd 0000:00:03.0: irq 10, io mem 0xd8410000
[ 8.042313] ata5.01: ATAPI: DV-28E-R, 1.8A, max UDMA/33
[ 8.058292] ata5.01: configured for UDMA/33
[ 8.085871] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[ 8.085877] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 8.085882] usb usb2: Product: OHCI Host Controller
[ 8.085886] usb usb2: Manufacturer: Linux 3.5.0-rc3+ ohci_hcd
[ 8.085891] usb usb2: SerialNumber: 0000:00:03.0
[ 8.086152] hub 2-0:1.0: USB hub found
[ 8.086162] hub 2-0:1.0: 2 ports detected
[ 8.086355] Already setup the GSI :10
[ 8.086381] ohci_hcd 0000:00:03.1: OHCI Host Controller
[ 8.086485] ohci_hcd 0000:00:03.1: new USB bus registered, assigned bus number 3
[ 8.086533] ohci_hcd 0000:00:03.1[ 8.972360] ata3: SATA link down (SStatus 4 SControl 300)
[ 9.300339] ata4: SATA link down (SStatus 4 SControl 300)
[ 9.304551] scsi 4:0:1:0: CD-ROM TEAC DV-28E-R 1.8A PQ: 0 ANSI: 5
[ 9.309465] sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda tray
[ 9.309471] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 9.309933] sr 4:0:1:0: Attached scsi generic sg1 type 5
[ 9.465898] md: Waiting for all devices to be available before autodetect
[ 9.465905] md: If you don't use raid, use raid=noautodetect
[ 9.466217] md: Autodetecting RAID arrays.
[ 9.466221] md: Scanned 0 and added 0 devices.
[ 9.466225] md: autorun ...
[ 9.466227] md: ... autorun DONE.
[ 9.618177] kjournald starting. Commit interval 5 seconds
[ 9.618515] EXT3-fs (sda2): using internal journal
[ 9.634755] EXT3-fs (sda2): recovery complete
[ 9.634773] EXT3-fs (sda2): mounted filesystem with writeback data mode
[ 9.634812] VFS: Mounted root (ext3 filesystem) on device 8:2.
[ 9.635302] Freeing unused kernel memory: 728k freed
[ 9.635605] Write protecting the kernel read-only data: 12288k
[ 9.642755] Freeing unused kernel memory: 1280k freed
[ 9.643732] Freeing unused kernel memory: 688k freed
[ 10.945707] udevd (1368): /proc/1368/oom_adj is deprecated, please use /proc/1368/oom_score_adj instead.
[ 10.945761] udevd version 128 started
[ 12.146999] Adding 7815584k swap on /dev/sda1. Priority:-1 extents:1 across:7815584k
[ 13.829592] dd: sending ioctl 801c6d02 to a partition!
[ 13.829613] dd: sending ioctl 80306d02 to a partition!
[ 13.829618] dd: sending ioctl 80306d02 to a partition!
[ 18.907214] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[-- Attachment #3: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpidump crashes on some machines
2012-06-20 12:37 acpidump crashes on some machines Andre Przywara
@ 2012-06-20 14:51 ` Konrad Rzeszutek Wilk
2012-06-21 14:21 ` Andre Przywara
2012-07-04 10:21 ` David Vrabel
1 sibling, 1 reply; 14+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-06-20 14:51 UTC (permalink / raw)
To: Andre Przywara; +Cc: Jeremy Fitzhardinge, xen-devel, Jan Beulich
On Wed, Jun 20, 2012 at 02:37:55PM +0200, Andre Przywara wrote:
> Hi,
>
> we have some problems with acpidump running on Xen Dom0. On 64 bit
> Dom0 it will trigger the OOM killer, on 32 bit Dom0s it will cause a
> kernel crash.
> The hypervisor does not matter, I tried 4.1.3-rc2 as well as various
> unstable versions including 25467, also 32-bit versions of 4.1.
> The Dom0 kernels were always PVOPS versions, the problems starts
> with 3.2-rc1~194 and is still in 3.5.0-rc3.
> Also you need to restrict the Dom0 memory with dom0_mem=
> The crash says (on a 3.4.3 32bit Dom0 kernel):
> uruk:~ # ./acpidump32
> [ 158.843444] ------------[ cut here ]------------
> [ 158.843460] kernel BUG at mm/rmap.c:1027!
> [ 158.843466] invalid opcode: 0000 [#1] SMP
> [ 158.843472] Modules linked in:
> [ 158.843478]
> [ 158.843483] Pid: 4874, comm: acpidump32 Tainted: G W
> 3.4.0+ #105 empty empty/S3993
> [ 158.843493] EIP: 0061:[<c10b0e27>] EFLAGS: 00010246 CPU: 3
> [ 158.843505] EIP is at __page_set_anon_rmap+0x12/0x45
> [ 158.843511] EAX: d6022dc0 EBX: dfecb6e0 ECX: b76faf64 EDX: b76faf64
> [ 158.843516] ESI: 00000000 EDI: b76faf64 EBP: d6091e8c ESP: d6091e84
> [ 158.843522] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
> [ 158.843529] CR0: 8005003b CR2: b76faf64 CR3: 17633000 CR4: 00000660
> [ 158.843535] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> [ 158.843581] DR6: ffff0ff0 DR7: 00000400
> [ 158.843586] Process acpidump32 (pid: 4874, ti=d6090000
> task=d60b34f0 task.ti=d6090000)
> [ 158.843591] Stack:
> [ 158.843594] dfecb6e0 00000001 d6091ea8 c10b15c4 00000000
> d6022dc0 d61fbdd8 d6022dc0
> [ 158.843610] 00000000 d6091efc c10aacbe 00000000 99948025
> 80000001 d8aa1f80 80000001
> [ 158.843631] dfefc800 00000000 d8aa1f80 00000000 166b7025
> d7f407d0 b76faf64 99948025
> [ 158.843649] Call Trace:
> [ 158.843656] [<c10b15c4>] do_page_add_anon_rmap+0x5b/0x64
> [ 158.843664] [<c10aacbe>] handle_pte_fault+0x81d/0xa06
> [ 158.843674] [<c10ab0ff>] handle_mm_fault+0x1fa/0x209
> [ 158.843683] [<c159e4e8>] ? spurious_fault+0x104/0x104
> [ 158.843688] [<c159e881>] do_page_fault+0x399/0x3b4
> [ 158.843696] [<c10c639d>] ? filp_close+0x55/0x5f
> [ 158.843701] [<c10c6408>] ? sys_close+0x61/0xa0
> [ 158.843706] [<c159e4e8>] ? spurious_fault+0x104/0x104
> [ 158.843714] [<c159c452>] error_code+0x5a/0x60
> [ 158.843720] [<c159e4e8>] ? spurious_fault+0x104/0x104
> [ 158.843724] Code: e8 45 91 00 00 89 c2 eb 09 2b 50 04 c1 ea 0c 03
> 50 4c 89 53 08 5b 5e 5d c3 55 89 e5 56 53 89 c3 89 d0 89 ca 8b 70 44
> 85 f6 75 02 <0f> 0b f6 43 04 01 75 27 83 7d 08 00 75 02 8b 36 46 89
> 73 04 f6
> [ 158.843824] EIP: [<c10b0e27>] __page_set_anon_rmap+0x12/0x45
> SS:ESP 0069:d6091e84
> [ 158.843848] ---[ end trace 4eaa2a86a8e2da24 ]---
> [ 158.843854] note: acpidump32[4874] exited with preempt_count 1
>
>
> On 64bit the OOM goes around, finally killing the login shell:
> uruk:~ # ./acpidump_inst
> acpi_map_memory(917504, 131072);
> opened /dev/mem (fd=3)
> calling mmap(NULL, 131072, PROT_READ, MAP_PRIVATE, fd, e0000);
> mmap returned 0xf7571000, function returns 0xf7571000
> acpi_map_table(cfef0f64, "XSDT");
> acpi_map_memory(3488550756, 36);
> opened /dev/mem (fd=3)
> calling mmap(NULL, 3976, PROT_READ, MAP_PRIVATE, fd, cfef0000);
> mmap returned 0xf76fd000, function returns 0xf76fdf64
> having mapped table header
> reading signature:
>
> Welcome to SUSE Linux Enterprise Server 11 SP1 (i586) - Kernel
> 3.5.0-rc3+ (hvc0).
>
> uruk login:
> -----------
> This dump shows that the bug happens the moment acpidump accesses
> the mmapped ACPI table at @cfef0000 (the lower map at e0000 works).
What is the e0000 one? I don't see in your E820 the region being
reserved?
>
> This is extra unfortunate as in SLES11 acpidump will be called by
> the kbd init script (querying the BIOS NumLock setting!)
Ah. Is the acpidump somewhere easily available to compile? Should
I get it from here:
http://www.lesswatts.org/projects/acpi/utilities.php
>
> I bisected the Dom0 kernel to find this one (v3.2-rc~194):
> commit 5eef150c1d7e41baaefd00dd56c153debcd86aee
> Merge: 315eb8a f3f436e
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Tue Oct 25 09:17:07 2011 +0200
>
> Merge branch 'stable/e820-3.2' of
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen
>
> * 'stable/e820-3.2' of
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
Oh boy. v3.2 .. that is eons ago! :-)
> xen: release all pages within 1-1 p2m mappings
> xen: allow extra memory to be in multiple regions
> xen: allow balloon driver to use more than one memory region
> xen/balloon: simplify test for the end of usable RAM
> xen/balloon: account for pages released during memory setup
>
>
> 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.
>
> 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?
[not compile tested]
#include <linux/module.h>
#include <linux/kthread.h>
#include <linux/pagemap.h>
#include <linux/init.h>
#include <xen/xen.h>
#define ACPITEST "0.1"
MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>");
MODULE_DESCRIPTION("acpitest");
MODULE_LICENSE("GPL");
MODULE_VERSION(ACPITEST);
static int __init acpitest_init(void)
{
unsigned int pfn = 0xcfef0;
unsigned int mfn;
void *data;
mfn = pfn_to_mfn(pfn);
WARN_ON(pfn != mfn, "We get %lx instead of %lx!\n", pfn, mfn);
if (pfn != mfn) {
printk(KERN_INFO "raw p2m (%lx) gives us: %lx\n", pfn, get_phys_to_machine(pfn));
return -EINVAL;
}
data = mfn_to_virt(mfn);
printk(KERN_INFO "va is 0x%lx\n", data);
print_hex_dump_bytes("acpi:", DUMP_PREFIX_OFFSET, data, PAGE_SIZE);
return 0;
}
static void __exit acpitest_exit(void)
{
}
module_init(acpitest_init);
module_exit(acpitest_exit);
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpidump crashes on some machines
2012-06-20 14:51 ` Konrad Rzeszutek Wilk
@ 2012-06-21 14:21 ` Andre Przywara
2012-06-30 1:48 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 14+ messages in thread
From: Andre Przywara @ 2012-06-21 14:21 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: Jeremy Fitzhardinge, xen-devel, Jan Beulich
On 06/20/2012 04:51 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Jun 20, 2012 at 02:37:55PM +0200, Andre Przywara wrote:
Konrad,
thanks for looking at the problem. Replies inline...
>> we have some problems with acpidump running on Xen Dom0. On 64 bit
>> Dom0 it will trigger the OOM killer, on 32 bit Dom0s it will cause a
>> kernel crash.
>> The hypervisor does not matter, I tried 4.1.3-rc2 as well as various
>> unstable versions including 25467, also 32-bit versions of 4.1.
>> The Dom0 kernels were always PVOPS versions, the problems starts
>> with 3.2-rc1~194 and is still in 3.5.0-rc3.
>> Also you need to restrict the Dom0 memory with dom0_mem=
>> The crash says (on a 3.4.3 32bit Dom0 kernel):
>> uruk:~ # ./acpidump32
>> [ 158.843444] ------------[ cut here ]------------
>> [ 158.843460] kernel BUG at mm/rmap.c:1027!
>> [ 158.843466] invalid opcode: 0000 [#1] SMP
>> [ 158.843472] Modules linked in:
>> [ 158.843478]
>> [ 158.843483] Pid: 4874, comm: acpidump32 Tainted: G W
>> 3.4.0+ #105 empty empty/S3993
>> [ 158.843493] EIP: 0061:[<c10b0e27>] EFLAGS: 00010246 CPU: 3
>> [ 158.843505] EIP is at __page_set_anon_rmap+0x12/0x45
>> [ 158.843511] EAX: d6022dc0 EBX: dfecb6e0 ECX: b76faf64 EDX: b76faf64
>> [ 158.843516] ESI: 00000000 EDI: b76faf64 EBP: d6091e8c ESP: d6091e84
>> [ 158.843522] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
>> [ 158.843529] CR0: 8005003b CR2: b76faf64 CR3: 17633000 CR4: 00000660
>> [ 158.843535] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
>> [ 158.843581] DR6: ffff0ff0 DR7: 00000400
>> [ 158.843586] Process acpidump32 (pid: 4874, ti=d6090000
>> task=d60b34f0 task.ti=d6090000)
>> [ 158.843591] Stack:
>> [ 158.843594] dfecb6e0 00000001 d6091ea8 c10b15c4 00000000
>> d6022dc0 d61fbdd8 d6022dc0
>> [ 158.843610] 00000000 d6091efc c10aacbe 00000000 99948025
>> 80000001 d8aa1f80 80000001
>> [ 158.843631] dfefc800 00000000 d8aa1f80 00000000 166b7025
>> d7f407d0 b76faf64 99948025
>> [ 158.843649] Call Trace:
>> [ 158.843656] [<c10b15c4>] do_page_add_anon_rmap+0x5b/0x64
>> [ 158.843664] [<c10aacbe>] handle_pte_fault+0x81d/0xa06
>> [ 158.843674] [<c10ab0ff>] handle_mm_fault+0x1fa/0x209
>> [ 158.843683] [<c159e4e8>] ? spurious_fault+0x104/0x104
>> [ 158.843688] [<c159e881>] do_page_fault+0x399/0x3b4
>> [ 158.843696] [<c10c639d>] ? filp_close+0x55/0x5f
>> [ 158.843701] [<c10c6408>] ? sys_close+0x61/0xa0
>> [ 158.843706] [<c159e4e8>] ? spurious_fault+0x104/0x104
>> [ 158.843714] [<c159c452>] error_code+0x5a/0x60
>> [ 158.843720] [<c159e4e8>] ? spurious_fault+0x104/0x104
>> [ 158.843724] Code: e8 45 91 00 00 89 c2 eb 09 2b 50 04 c1 ea 0c 03
>> 50 4c 89 53 08 5b 5e 5d c3 55 89 e5 56 53 89 c3 89 d0 89 ca 8b 70 44
>> 85 f6 75 02<0f> 0b f6 43 04 01 75 27 83 7d 08 00 75 02 8b 36 46 89
>> 73 04 f6
>> [ 158.843824] EIP: [<c10b0e27>] __page_set_anon_rmap+0x12/0x45
>> SS:ESP 0069:d6091e84
>> [ 158.843848] ---[ end trace 4eaa2a86a8e2da24 ]---
>> [ 158.843854] note: acpidump32[4874] exited with preempt_count 1
>>
>>
>> On 64bit the OOM goes around, finally killing the login shell:
>> uruk:~ # ./acpidump_inst
>> acpi_map_memory(917504, 131072);
>> opened /dev/mem (fd=3)
>> calling mmap(NULL, 131072, PROT_READ, MAP_PRIVATE, fd, e0000);
>> mmap returned 0xf7571000, function returns 0xf7571000
>> acpi_map_table(cfef0f64, "XSDT");
>> acpi_map_memory(3488550756, 36);
>> opened /dev/mem (fd=3)
>> calling mmap(NULL, 3976, PROT_READ, MAP_PRIVATE, fd, cfef0000);
>> mmap returned 0xf76fd000, function returns 0xf76fdf64
>> having mapped table header
>> reading signature:
>>
>> Welcome to SUSE Linux Enterprise Server 11 SP1 (i586) - Kernel
>> 3.5.0-rc3+ (hvc0).
>>
>> uruk login:
>> -----------
>> This dump shows that the bug happens the moment acpidump accesses
>> the mmapped ACPI table at @cfef0000 (the lower map at e0000 works).
>
> What is the e0000 one? I don't see in your E820 the region being
> reserved?
E0000 is the below 1 MB BIOS area with the ACPI RSDP root pointer.
E000:0000 in old DOS speak. The ACPI spec says that the pointer to the
tables is hidden somewhere between 896K and 1MB at 16 byte granularity.
acpidump scans this area for the ACPI magic number.
So mapping /dev/mem is not fully broken, as this part at least works.
>>
>> This is extra unfortunate as in SLES11 acpidump will be called by
>> the kbd init script (querying the BIOS NumLock setting!)
>
> Ah. Is the acpidump somewhere easily available to compile? Should
> I get it from here:
> http://www.lesswatts.org/projects/acpi/utilities.php
Right, it is in the pmtools-20071116.tar.gz archive. Just say make in
the acpidump directory.
>>
>> I bisected the Dom0 kernel to find this one (v3.2-rc~194):
>> commit 5eef150c1d7e41baaefd00dd56c153debcd86aee
>> Merge: 315eb8a f3f436e
>> Author: Linus Torvalds<torvalds@linux-foundation.org>
>> Date: Tue Oct 25 09:17:07 2011 +0200
>>
>> Merge branch 'stable/e820-3.2' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen
>>
>> * 'stable/e820-3.2' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
>
> Oh boy. v3.2 .. that is eons ago! :-)
Tell that those 2.6.32 or even 2.6.18 users...
>
>> xen: release all pages within 1-1 p2m mappings
>> xen: allow extra memory to be in multiple regions
>> xen: allow balloon driver to use more than one memory region
>> xen/balloon: simplify test for the end of usable RAM
>> xen/balloon: account for pages released during memory setup
>>
>>
>> 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
>>
>> 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!
[ 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):
# insmod testxenmap.ko pfn=0xcfef0
[ 243.071693] va is 0xffff8800cfef0000
[ 243.071710] BUG: unable to handle kernel paging request at
ffff8800cfef0000
[ 243.071733] IP: [<ffffffff81275a22>] hex_dump_to_buffer+0x19c/0x282
[ 243.071742] PGD 1c0c067 PUD f5b067 PMD fdb067 PTE 0
[ 243.071748] Oops: 0000 [#1] SMP
[ 243.071753] CPU 5
[ 243.071757] Modules linked in: testxenmap(O+) [last unloaded: testxenmap]
[ 243.071762]
[ 243.071768] Pid: 4825, comm: insmod Tainted: G W O 3.5.0-rc3+
#106 empty empty/S3993
[ 243.071777] RIP: e030:[<ffffffff81275a22>] [<ffffffff81275a22>]
hex_dump_to_buffer+0x19c/0x282
[ 243.071783] RSP: e02b:ffff880312e2fd58 EFLAGS: 00010203
...
Hope that helps and thanks!
Andre.
> [not compile tested]
ACK ;-)
>
> #include<linux/module.h>
> #include<linux/kthread.h>
> #include<linux/pagemap.h>
> #include<linux/init.h>
> #include<xen/xen.h>
+ #include<xen/page.h>
> #define ACPITEST "0.1"
>
> MODULE_AUTHOR("Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>");
> MODULE_DESCRIPTION("acpitest");
> MODULE_LICENSE("GPL");
> MODULE_VERSION(ACPITEST);
>
+unsigned long pfn = 0xcfef0;
+module_param(pfn, ulong, 0644);
+MODULE_PARM_DESC(pfn, "pfn to test");
+
> static int __init acpitest_init(void)
> {
- unsigned int pfn = 0xcfef0;
- unsigned int mfn;
+ unsigned long mfn;
> void *data;
>
> mfn = pfn_to_mfn(pfn);
- WARN_ON(pfn != mfn, "We get %lx instead of %lx!\n", pfn, mfn);
+ WARN(pfn != mfn, "We get %lx instead of %lx!\n", pfn, mfn);
> if (pfn != mfn) {
> printk(KERN_INFO "raw p2m (%lx) gives us: %lx\n", pfn, get_phys_to_machine(pfn));
> return -EINVAL;
> }
> data = mfn_to_virt(mfn);
- printk(KERN_INFO "va is 0x%lx\n", data);
+ printk(KERN_INFO "va is 0x%p\n", data);
> print_hex_dump_bytes("acpi:", DUMP_PREFIX_OFFSET, data, PAGE_SIZE);
>
> return 0;
> }
> static void __exit acpitest_exit(void)
> {
> }
> module_init(acpitest_init);
> module_exit(acpitest_exit);
>
>
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpidump crashes on some machines
2012-06-21 14:21 ` Andre Przywara
@ 2012-06-30 1:48 ` Konrad Rzeszutek Wilk
2012-06-30 2:19 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 14+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-06-30 1:48 UTC (permalink / raw)
To: Andre Przywara; +Cc: Jeremy Fitzhardinge, xen-devel, Jan Beulich
> >>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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpidump crashes on some machines
2012-06-30 1:48 ` Konrad Rzeszutek Wilk
@ 2012-06-30 2:19 ` Konrad Rzeszutek Wilk
2012-07-26 13:02 ` Andre Przywara
0 siblings, 1 reply; 14+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-06-30 2:19 UTC (permalink / raw)
To: Andre Przywara; +Cc: Jeremy Fitzhardinge, xen-devel, Jan Beulich
> > [ 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpidump crashes on some machines
2012-06-20 12:37 acpidump crashes on some machines Andre Przywara
2012-06-20 14:51 ` Konrad Rzeszutek Wilk
@ 2012-07-04 10:21 ` David Vrabel
1 sibling, 0 replies; 14+ messages in thread
From: David Vrabel @ 2012-07-04 10:21 UTC (permalink / raw)
To: Andre Przywara
Cc: Jeremy Fitzhardinge, xen-devel, Jan Beulich, Konrad Rzeszutek Wilk
On 20/06/12 13:37, Andre Przywara wrote:
> Hi,
>
> we have some problems with acpidump running on Xen Dom0. On 64 bit Dom0
> it will trigger the OOM killer, on 32 bit Dom0s it will cause a kernel
> crash.
> The hypervisor does not matter, I tried 4.1.3-rc2 as well as various
> unstable versions including 25467, also 32-bit versions of 4.1.
> The Dom0 kernels were always PVOPS versions, the problems starts with
> 3.2-rc1~194 and is still in 3.5.0-rc3.
> Also you need to restrict the Dom0 memory with dom0_mem=
This is odd. Can you try a range of dom0_mem settings to see which
values cause this?
David
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpidump crashes on some machines
2012-06-30 2:19 ` Konrad Rzeszutek Wilk
@ 2012-07-26 13:02 ` Andre Przywara
2012-08-17 20:52 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 14+ messages in thread
From: Andre Przywara @ 2012-07-26 13:02 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, david.vrabel
Cc: Jeremy Fitzhardinge, xen-devel, Jan Beulich
On 06/30/2012 04:19 AM, Konrad Rzeszutek Wilk wrote:
Konrad, David,
back on track for this issue. Thanks for your input, I could do some
more debugging (see below for a refresh):
It seems like it affects only the first page of the 1:1 mapping. I
didn't have an issues with the last PFN or the page behind it (which
failed properly).
David, thanks for the hint with varying dom0_mem parameter. I thought I
already checked this, but I did it once again and it turned out that it
is only an issue if dom0_mem is smaller than the ACPI area, which
generates a hole in the memory map. So we have (simplified)
* 1:1 mapping to 1 MB
* normal mapping till dom0_mem
* unmapped area till ACPI E820 area
* ACPI E820 1:1 mapping
As far as I could chase it down the 1:1 mapping itself looks OK, I
couldn't find any off-by-one bugs here. So maybe it is code that later
on invalidates areas between the normal guest mapping and the ACPI mem?
Hope that helps, I will also try to find more about this.
Thanks,
Andre.
>>> [ 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.
>
>
--
Andre Przywara
AMD-OSRC (Dresden)
Tel: x29712
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpidump crashes on some machines
2012-07-26 13:02 ` Andre Przywara
@ 2012-08-17 20:52 ` Konrad Rzeszutek Wilk
2012-08-23 10:14 ` Andre Przywara
0 siblings, 1 reply; 14+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-08-17 20:52 UTC (permalink / raw)
To: Andre Przywara; +Cc: Jeremy Fitzhardinge, xen-devel, david.vrabel, Jan Beulich
On Thu, Jul 26, 2012 at 03:02:58PM +0200, Andre Przywara wrote:
> On 06/30/2012 04:19 AM, Konrad Rzeszutek Wilk wrote:
>
> Konrad, David,
>
> back on track for this issue. Thanks for your input, I could do some
> more debugging (see below for a refresh):
>
> It seems like it affects only the first page of the 1:1 mapping. I
> didn't have an issues with the last PFN or the page behind it (which
> failed properly).
>
> David, thanks for the hint with varying dom0_mem parameter. I
> thought I already checked this, but I did it once again and it
> turned out that it is only an issue if dom0_mem is smaller than the
> ACPI area, which generates a hole in the memory map. So we have
> (simplified)
> * 1:1 mapping to 1 MB
> * normal mapping till dom0_mem
> * unmapped area till ACPI E820 area
> * ACPI E820 1:1 mapping
>
> As far as I could chase it down the 1:1 mapping itself looks OK, I
> couldn't find any off-by-one bugs here. So maybe it is code that
> later on invalidates areas between the normal guest mapping and the
> ACPI mem?
I think I found it. Can you try this pls [and if you can't find
early_to_phys.. just use the __set_phys_to call]
>From ab915d98f321b0fcca1932747c632b5f0f299f55 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 17 Aug 2012 16:43:28 -0400
Subject: [PATCH] xen/setup: Fix one-off error when adding for-balloon PFNs to
the P2M.
When we are finished with return PFNs to the hypervisor, then
populate it back, and also mark the E820 MMIO and E820 gaps
as IDENTITY_FRAMEs, we then call P2M to set areas that can
be used for ballooning. We were off by one, and ended up
over-writting a P2M entry that most likely was an IDENTITY_FRAME.
For example:
1-1 mapping on 40000->40200
1-1 mapping on bc558->bc5ac
1-1 mapping on bc5b4->bc8c5
1-1 mapping on bc8c6->bcb7c
1-1 mapping on bcd00->100000
Released 614 pages of unused memory
Set 277889 page(s) to 1-1 mapping
Populating 40200-40466 pfn range: 614 pages added
=> here we set from 40466 up to bc559 P2M tree to be
INVALID_P2M_ENTRY. We should have done it up to bc558.
The end result is that if anybody is trying to construct
a PTE for PFN bc558 they end up with ~PAGE_PRESENT.
CC: stable@vger.kernel.org
Reported-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
arch/x86/xen/setup.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index ead8557..030a55a 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -78,9 +78,16 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
memblock_reserve(start, size);
xen_max_p2m_pfn = PFN_DOWN(start + size);
+ for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
+ unsigned long mfn = pfn_to_mfn(pfn);
+
+ if (WARN(mfn == pfn, "Trying to over-write 1-1 mapping (pfn: %lx)\n", pfn))
+ continue;
+ WARN(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has %lx mfn!\n",
+ pfn, mfn);
- for (pfn = PFN_DOWN(start); pfn <= xen_max_p2m_pfn; pfn++)
- __set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
+ early_set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
+ }
}
static unsigned long __init xen_do_chunk(unsigned long start,
--
1.7.7.6
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: acpidump crashes on some machines
2012-08-17 20:52 ` Konrad Rzeszutek Wilk
@ 2012-08-23 10:14 ` Andre Przywara
2012-08-23 10:22 ` David Vrabel
2012-08-23 14:06 ` Konrad Rzeszutek Wilk
0 siblings, 2 replies; 14+ messages in thread
From: Andre Przywara @ 2012-08-23 10:14 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Jeremy Fitzhardinge, xen-devel, david.vrabel, Jan Beulich
On 08/17/2012 10:52 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Jul 26, 2012 at 03:02:58PM +0200, Andre Przywara wrote:
>> On 06/30/2012 04:19 AM, Konrad Rzeszutek Wilk wrote:
>>
>> Konrad, David,
>>
>> back on track for this issue. Thanks for your input, I could do some
>> more debugging (see below for a refresh):
>>
>> It seems like it affects only the first page of the 1:1 mapping. I
>> didn't have an issues with the last PFN or the page behind it (which
>> failed properly).
>>
>> David, thanks for the hint with varying dom0_mem parameter. I
>> thought I already checked this, but I did it once again and it
>> turned out that it is only an issue if dom0_mem is smaller than the
>> ACPI area, which generates a hole in the memory map. So we have
>> (simplified)
>> * 1:1 mapping to 1 MB
>> * normal mapping till dom0_mem
>> * unmapped area till ACPI E820 area
>> * ACPI E820 1:1 mapping
>>
>> As far as I could chase it down the 1:1 mapping itself looks OK, I
>> couldn't find any off-by-one bugs here. So maybe it is code that
>> later on invalidates areas between the normal guest mapping and the
>> ACPI mem?
>
> I think I found it. Can you try this pls [and if you can't find
> early_to_phys.. just use the __set_phys_to call]
Yes, that works. At least after a quick test on my test box. Both the
test module and acpidump work as expected. If I replace the "<" in your
patch with the original "<=", I get the warning (and due to the
"continue" it also works).
I also successfully tested the minimal fix (just replacing <= with <).
I will feed it to the testers here to cover more machines.
Do you want to keep the warnings in (which exceed 80 characters, btw)?
Thanks a lot and:
Tested-by: Andre Przywara <andre.przywara@amd.com>
Regards,
Andre.
>
> From ab915d98f321b0fcca1932747c632b5f0f299f55 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Fri, 17 Aug 2012 16:43:28 -0400
> Subject: [PATCH] xen/setup: Fix one-off error when adding for-balloon PFNs to
> the P2M.
>
> When we are finished with return PFNs to the hypervisor, then
> populate it back, and also mark the E820 MMIO and E820 gaps
> as IDENTITY_FRAMEs, we then call P2M to set areas that can
> be used for ballooning. We were off by one, and ended up
> over-writting a P2M entry that most likely was an IDENTITY_FRAME.
> For example:
>
> 1-1 mapping on 40000->40200
> 1-1 mapping on bc558->bc5ac
> 1-1 mapping on bc5b4->bc8c5
> 1-1 mapping on bc8c6->bcb7c
> 1-1 mapping on bcd00->100000
> Released 614 pages of unused memory
> Set 277889 page(s) to 1-1 mapping
> Populating 40200-40466 pfn range: 614 pages added
>
> => here we set from 40466 up to bc559 P2M tree to be
> INVALID_P2M_ENTRY. We should have done it up to bc558.
>
> The end result is that if anybody is trying to construct
> a PTE for PFN bc558 they end up with ~PAGE_PRESENT.
>
> CC: stable@vger.kernel.org
> Reported-by: Andre Przywara <andre.przywara@amd.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> arch/x86/xen/setup.c | 11 +++++++++--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index ead8557..030a55a 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -78,9 +78,16 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
> memblock_reserve(start, size);
>
> xen_max_p2m_pfn = PFN_DOWN(start + size);
> + for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
> + unsigned long mfn = pfn_to_mfn(pfn);
> +
> + if (WARN(mfn == pfn, "Trying to over-write 1-1 mapping (pfn: %lx)\n", pfn))
> + continue;
> + WARN(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has %lx mfn!\n",
> + pfn, mfn);
>
> - for (pfn = PFN_DOWN(start); pfn <= xen_max_p2m_pfn; pfn++)
> - __set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
> + early_set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
> + }
> }
>
> static unsigned long __init xen_do_chunk(unsigned long start,
>
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpidump crashes on some machines
2012-08-23 10:14 ` Andre Przywara
@ 2012-08-23 10:22 ` David Vrabel
2012-08-23 14:10 ` Konrad Rzeszutek Wilk
2012-08-23 14:06 ` Konrad Rzeszutek Wilk
1 sibling, 1 reply; 14+ messages in thread
From: David Vrabel @ 2012-08-23 10:22 UTC (permalink / raw)
To: Andre Przywara
Cc: Jeremy Fitzhardinge, xen-devel, Jan Beulich, Konrad Rzeszutek Wilk
On 23/08/12 11:14, Andre Przywara wrote:
> On 08/17/2012 10:52 PM, Konrad Rzeszutek Wilk wrote:
>> On Thu, Jul 26, 2012 at 03:02:58PM +0200, Andre Przywara wrote:
>>> On 06/30/2012 04:19 AM, Konrad Rzeszutek Wilk wrote:
>>>
>>> Konrad, David,
>>>
>>> back on track for this issue. Thanks for your input, I could do some
>>> more debugging (see below for a refresh):
>>>
>>> It seems like it affects only the first page of the 1:1 mapping. I
>>> didn't have an issues with the last PFN or the page behind it (which
>>> failed properly).
>>>
>>> David, thanks for the hint with varying dom0_mem parameter. I
>>> thought I already checked this, but I did it once again and it
>>> turned out that it is only an issue if dom0_mem is smaller than the
>>> ACPI area, which generates a hole in the memory map. So we have
>>> (simplified)
>>> * 1:1 mapping to 1 MB
>>> * normal mapping till dom0_mem
>>> * unmapped area till ACPI E820 area
>>> * ACPI E820 1:1 mapping
>>>
>>> As far as I could chase it down the 1:1 mapping itself looks OK, I
>>> couldn't find any off-by-one bugs here. So maybe it is code that
>>> later on invalidates areas between the normal guest mapping and the
>>> ACPI mem?
>>
>> I think I found it. Can you try this pls [and if you can't find
>> early_to_phys.. just use the __set_phys_to call]
>
> Yes, that works. At least after a quick test on my test box. Both the
> test module and acpidump work as expected. If I replace the "<" in your
> patch with the original "<=", I get the warning (and due to the
> "continue" it also works).
Note that the balloon driver could subsequently overwrite the p2m entry.
I don't think it is worth redoing the patch to adjust the region passed
to the balloon driver to avoid this though.
> I also successfully tested the minimal fix (just replacing <= with <).
> I will feed it to the testers here to cover more machines.
>
> Do you want to keep the warnings in (which exceed 80 characters, btw)?
I think we do.
David
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpidump crashes on some machines
2012-08-23 10:14 ` Andre Przywara
2012-08-23 10:22 ` David Vrabel
@ 2012-08-23 14:06 ` Konrad Rzeszutek Wilk
1 sibling, 0 replies; 14+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-08-23 14:06 UTC (permalink / raw)
To: Andre Przywara; +Cc: Jeremy Fitzhardinge, xen-devel, david.vrabel, Jan Beulich
On Thu, Aug 23, 2012 at 12:14:56PM +0200, Andre Przywara wrote:
> On 08/17/2012 10:52 PM, Konrad Rzeszutek Wilk wrote:
> >On Thu, Jul 26, 2012 at 03:02:58PM +0200, Andre Przywara wrote:
> >>On 06/30/2012 04:19 AM, Konrad Rzeszutek Wilk wrote:
> >>
> >>Konrad, David,
> >>
> >>back on track for this issue. Thanks for your input, I could do some
> >>more debugging (see below for a refresh):
> >>
> >>It seems like it affects only the first page of the 1:1 mapping. I
> >>didn't have an issues with the last PFN or the page behind it (which
> >>failed properly).
> >>
> >>David, thanks for the hint with varying dom0_mem parameter. I
> >>thought I already checked this, but I did it once again and it
> >>turned out that it is only an issue if dom0_mem is smaller than the
> >>ACPI area, which generates a hole in the memory map. So we have
> >>(simplified)
> >>* 1:1 mapping to 1 MB
> >>* normal mapping till dom0_mem
> >>* unmapped area till ACPI E820 area
> >>* ACPI E820 1:1 mapping
> >>
> >>As far as I could chase it down the 1:1 mapping itself looks OK, I
> >>couldn't find any off-by-one bugs here. So maybe it is code that
> >>later on invalidates areas between the normal guest mapping and the
> >>ACPI mem?
> >
> >I think I found it. Can you try this pls [and if you can't find
> >early_to_phys.. just use the __set_phys_to call]
>
> Yes, that works. At least after a quick test on my test box. Both
> the test module and acpidump work as expected. If I replace the "<"
> in your patch with the original "<=", I get the warning (and due to
> the "continue" it also works).
> I also successfully tested the minimal fix (just replacing <= with <).
> I will feed it to the testers here to cover more machines.
>
> Do you want to keep the warnings in (which exceed 80 characters, btw)?
Yes. The new style is to allow any type of printk/WARN etc to be unbroken
and break the 80 characters.
>
> Thanks a lot and:
>
> Tested-by: Andre Przywara <andre.przywara@amd.com>
Great. Thx.
>
> Regards,
> Andre.
>
> >
> > From ab915d98f321b0fcca1932747c632b5f0f299f55 Mon Sep 17 00:00:00 2001
> >From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >Date: Fri, 17 Aug 2012 16:43:28 -0400
> >Subject: [PATCH] xen/setup: Fix one-off error when adding for-balloon PFNs to
> > the P2M.
> >
> >When we are finished with return PFNs to the hypervisor, then
> >populate it back, and also mark the E820 MMIO and E820 gaps
> >as IDENTITY_FRAMEs, we then call P2M to set areas that can
> >be used for ballooning. We were off by one, and ended up
> >over-writting a P2M entry that most likely was an IDENTITY_FRAME.
> >For example:
> >
> >1-1 mapping on 40000->40200
> >1-1 mapping on bc558->bc5ac
> >1-1 mapping on bc5b4->bc8c5
> >1-1 mapping on bc8c6->bcb7c
> >1-1 mapping on bcd00->100000
> >Released 614 pages of unused memory
> >Set 277889 page(s) to 1-1 mapping
> >Populating 40200-40466 pfn range: 614 pages added
> >
> >=> here we set from 40466 up to bc559 P2M tree to be
> >INVALID_P2M_ENTRY. We should have done it up to bc558.
> >
> >The end result is that if anybody is trying to construct
> >a PTE for PFN bc558 they end up with ~PAGE_PRESENT.
> >
> >CC: stable@vger.kernel.org
> >Reported-by: Andre Przywara <andre.przywara@amd.com>
> >Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >---
> > arch/x86/xen/setup.c | 11 +++++++++--
> > 1 files changed, 9 insertions(+), 2 deletions(-)
> >
> >diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> >index ead8557..030a55a 100644
> >--- a/arch/x86/xen/setup.c
> >+++ b/arch/x86/xen/setup.c
> >@@ -78,9 +78,16 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
> > memblock_reserve(start, size);
> >
> > xen_max_p2m_pfn = PFN_DOWN(start + size);
> >+ for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
> >+ unsigned long mfn = pfn_to_mfn(pfn);
> >+
> >+ if (WARN(mfn == pfn, "Trying to over-write 1-1 mapping (pfn: %lx)\n", pfn))
> >+ continue;
> >+ WARN(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has %lx mfn!\n",
> >+ pfn, mfn);
> >
> >- for (pfn = PFN_DOWN(start); pfn <= xen_max_p2m_pfn; pfn++)
> >- __set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
> >+ early_set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
> >+ }
> > }
> >
> > static unsigned long __init xen_do_chunk(unsigned long start,
> >
>
> --
> Andre Przywara
> AMD-Operating System Research Center (OSRC), Dresden, Germany
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpidump crashes on some machines
2012-08-23 10:22 ` David Vrabel
@ 2012-08-23 14:10 ` Konrad Rzeszutek Wilk
2012-08-23 14:36 ` David Vrabel
0 siblings, 1 reply; 14+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-08-23 14:10 UTC (permalink / raw)
To: David Vrabel; +Cc: Andre Przywara, Jeremy Fitzhardinge, xen-devel, Jan Beulich
On Thu, Aug 23, 2012 at 11:22:29AM +0100, David Vrabel wrote:
> On 23/08/12 11:14, Andre Przywara wrote:
> > On 08/17/2012 10:52 PM, Konrad Rzeszutek Wilk wrote:
> >> On Thu, Jul 26, 2012 at 03:02:58PM +0200, Andre Przywara wrote:
> >>> On 06/30/2012 04:19 AM, Konrad Rzeszutek Wilk wrote:
> >>>
> >>> Konrad, David,
> >>>
> >>> back on track for this issue. Thanks for your input, I could do some
> >>> more debugging (see below for a refresh):
> >>>
> >>> It seems like it affects only the first page of the 1:1 mapping. I
> >>> didn't have an issues with the last PFN or the page behind it (which
> >>> failed properly).
> >>>
> >>> David, thanks for the hint with varying dom0_mem parameter. I
> >>> thought I already checked this, but I did it once again and it
> >>> turned out that it is only an issue if dom0_mem is smaller than the
> >>> ACPI area, which generates a hole in the memory map. So we have
> >>> (simplified)
> >>> * 1:1 mapping to 1 MB
> >>> * normal mapping till dom0_mem
> >>> * unmapped area till ACPI E820 area
> >>> * ACPI E820 1:1 mapping
> >>>
> >>> As far as I could chase it down the 1:1 mapping itself looks OK, I
> >>> couldn't find any off-by-one bugs here. So maybe it is code that
> >>> later on invalidates areas between the normal guest mapping and the
> >>> ACPI mem?
> >>
> >> I think I found it. Can you try this pls [and if you can't find
> >> early_to_phys.. just use the __set_phys_to call]
> >
> > Yes, that works. At least after a quick test on my test box. Both the
> > test module and acpidump work as expected. If I replace the "<" in your
> > patch with the original "<=", I get the warning (and due to the
> > "continue" it also works).
>
> Note that the balloon driver could subsequently overwrite the p2m entry.
Hmm, I am not seeing how.. the region that is passed in is right up to
the PFN (I believe). And I did run with this patch over a couple of days
with ballooning up and down. But maybe I missed something?
Let me prep a patch that adds some more checks in the balloon driver
just in case we do hit this.
> I don't think it is worth redoing the patch to adjust the region passed
> to the balloon driver to avoid this though.
>
> > I also successfully tested the minimal fix (just replacing <= with <).
> > I will feed it to the testers here to cover more machines.
> >
> > Do you want to keep the warnings in (which exceed 80 characters, btw)?
>
> I think we do.
>
> David
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpidump crashes on some machines
2012-08-23 14:36 ` David Vrabel
@ 2012-08-23 14:35 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 14+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-08-23 14:35 UTC (permalink / raw)
To: David Vrabel; +Cc: Andre Przywara, Jeremy Fitzhardinge, xen-devel, Jan Beulich
On Thu, Aug 23, 2012 at 03:36:31PM +0100, David Vrabel wrote:
> On 23/08/12 15:10, Konrad Rzeszutek Wilk wrote:
> > On Thu, Aug 23, 2012 at 11:22:29AM +0100, David Vrabel wrote:
> >> On 23/08/12 11:14, Andre Przywara wrote:
> >>> On 08/17/2012 10:52 PM, Konrad Rzeszutek Wilk wrote:
> >>>> On Thu, Jul 26, 2012 at 03:02:58PM +0200, Andre Przywara wrote:
> >>>>> On 06/30/2012 04:19 AM, Konrad Rzeszutek Wilk wrote:
> >>>>>
> >>>>> Konrad, David,
> >>>>>
> >>>>> back on track for this issue. Thanks for your input, I could do some
> >>>>> more debugging (see below for a refresh):
> >>>>>
> >>>>> It seems like it affects only the first page of the 1:1 mapping. I
> >>>>> didn't have an issues with the last PFN or the page behind it (which
> >>>>> failed properly).
> >>>>>
> >>>>> David, thanks for the hint with varying dom0_mem parameter. I
> >>>>> thought I already checked this, but I did it once again and it
> >>>>> turned out that it is only an issue if dom0_mem is smaller than the
> >>>>> ACPI area, which generates a hole in the memory map. So we have
> >>>>> (simplified)
> >>>>> * 1:1 mapping to 1 MB
> >>>>> * normal mapping till dom0_mem
> >>>>> * unmapped area till ACPI E820 area
> >>>>> * ACPI E820 1:1 mapping
> >>>>>
> >>>>> As far as I could chase it down the 1:1 mapping itself looks OK, I
> >>>>> couldn't find any off-by-one bugs here. So maybe it is code that
> >>>>> later on invalidates areas between the normal guest mapping and the
> >>>>> ACPI mem?
> >>>>
> >>>> I think I found it. Can you try this pls [and if you can't find
> >>>> early_to_phys.. just use the __set_phys_to call]
> >>>
> >>> Yes, that works. At least after a quick test on my test box. Both the
> >>> test module and acpidump work as expected. If I replace the "<" in your
> >>> patch with the original "<=", I get the warning (and due to the
> >>> "continue" it also works).
> >>
> >> Note that the balloon driver could subsequently overwrite the p2m entry.
> >
> > Hmm, I am not seeing how.. the region that is passed in is right up to
> > the PFN (I believe). And I did run with this patch over a couple of days
> > with ballooning up and down. But maybe I missed something?
>
> Hrrm. I was sure I wrote "Note that the balloon driver could
> subsequently overwrite the p2m entry /if/ this warning is triggered."
> but it seems I did not. :/
>
> i.e., if the warning is triggered, the xen_extra_mem region will be
> incorrectly sized and the balloon driver will make use of the incorrect
> region.
Ah, that makes more sense. Yes we would do the overwritting part later on
in that scenario.. which makes me wonder - if we did that in the past
how come MMIO devices still worked! Some boxes have the gap/MMIO right
at the edge of the E820_RAM - perhaps they silently coping with and
we just never caught on this fact.
>
> David
>
> > Let me prep a patch that adds some more checks in the balloon driver
> > just in case we do hit this.
> >
> >> I don't think it is worth redoing the patch to adjust the region passed
> >> to the balloon driver to avoid this though.
> >>
> >>> I also successfully tested the minimal fix (just replacing <= with <).
> >>> I will feed it to the testers here to cover more machines.
> >>>
> >>> Do you want to keep the warnings in (which exceed 80 characters, btw)?
> >>
> >> I think we do.
> >>
> >> David
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpidump crashes on some machines
2012-08-23 14:10 ` Konrad Rzeszutek Wilk
@ 2012-08-23 14:36 ` David Vrabel
2012-08-23 14:35 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 14+ messages in thread
From: David Vrabel @ 2012-08-23 14:36 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Andre Przywara, Jeremy Fitzhardinge, xen-devel, Jan Beulich
On 23/08/12 15:10, Konrad Rzeszutek Wilk wrote:
> On Thu, Aug 23, 2012 at 11:22:29AM +0100, David Vrabel wrote:
>> On 23/08/12 11:14, Andre Przywara wrote:
>>> On 08/17/2012 10:52 PM, Konrad Rzeszutek Wilk wrote:
>>>> On Thu, Jul 26, 2012 at 03:02:58PM +0200, Andre Przywara wrote:
>>>>> On 06/30/2012 04:19 AM, Konrad Rzeszutek Wilk wrote:
>>>>>
>>>>> Konrad, David,
>>>>>
>>>>> back on track for this issue. Thanks for your input, I could do some
>>>>> more debugging (see below for a refresh):
>>>>>
>>>>> It seems like it affects only the first page of the 1:1 mapping. I
>>>>> didn't have an issues with the last PFN or the page behind it (which
>>>>> failed properly).
>>>>>
>>>>> David, thanks for the hint with varying dom0_mem parameter. I
>>>>> thought I already checked this, but I did it once again and it
>>>>> turned out that it is only an issue if dom0_mem is smaller than the
>>>>> ACPI area, which generates a hole in the memory map. So we have
>>>>> (simplified)
>>>>> * 1:1 mapping to 1 MB
>>>>> * normal mapping till dom0_mem
>>>>> * unmapped area till ACPI E820 area
>>>>> * ACPI E820 1:1 mapping
>>>>>
>>>>> As far as I could chase it down the 1:1 mapping itself looks OK, I
>>>>> couldn't find any off-by-one bugs here. So maybe it is code that
>>>>> later on invalidates areas between the normal guest mapping and the
>>>>> ACPI mem?
>>>>
>>>> I think I found it. Can you try this pls [and if you can't find
>>>> early_to_phys.. just use the __set_phys_to call]
>>>
>>> Yes, that works. At least after a quick test on my test box. Both the
>>> test module and acpidump work as expected. If I replace the "<" in your
>>> patch with the original "<=", I get the warning (and due to the
>>> "continue" it also works).
>>
>> Note that the balloon driver could subsequently overwrite the p2m entry.
>
> Hmm, I am not seeing how.. the region that is passed in is right up to
> the PFN (I believe). And I did run with this patch over a couple of days
> with ballooning up and down. But maybe I missed something?
Hrrm. I was sure I wrote "Note that the balloon driver could
subsequently overwrite the p2m entry /if/ this warning is triggered."
but it seems I did not. :/
i.e., if the warning is triggered, the xen_extra_mem region will be
incorrectly sized and the balloon driver will make use of the incorrect
region.
David
> Let me prep a patch that adds some more checks in the balloon driver
> just in case we do hit this.
>
>> I don't think it is worth redoing the patch to adjust the region passed
>> to the balloon driver to avoid this though.
>>
>>> I also successfully tested the minimal fix (just replacing <= with <).
>>> I will feed it to the testers here to cover more machines.
>>>
>>> Do you want to keep the warnings in (which exceed 80 characters, btw)?
>>
>> I think we do.
>>
>> David
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2012-08-23 14:36 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-20 12:37 acpidump crashes on some machines Andre Przywara
2012-06-20 14:51 ` Konrad Rzeszutek Wilk
2012-06-21 14:21 ` Andre Przywara
2012-06-30 1:48 ` Konrad Rzeszutek Wilk
2012-06-30 2:19 ` Konrad Rzeszutek Wilk
2012-07-26 13:02 ` Andre Przywara
2012-08-17 20:52 ` Konrad Rzeszutek Wilk
2012-08-23 10:14 ` Andre Przywara
2012-08-23 10:22 ` David Vrabel
2012-08-23 14:10 ` Konrad Rzeszutek Wilk
2012-08-23 14:36 ` David Vrabel
2012-08-23 14:35 ` Konrad Rzeszutek Wilk
2012-08-23 14:06 ` Konrad Rzeszutek Wilk
2012-07-04 10:21 ` David Vrabel
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.