All of lore.kernel.org
 help / color / mirror / Atom feed
* Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
@ 2010-02-24 18:47 George Dunlap
  2010-02-24 19:08 ` Sander Eikelenboom
  0 siblings, 1 reply; 26+ messages in thread
From: George Dunlap @ 2010-02-24 18:47 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: Type: text/plain, Size: 3509 bytes --]

I recenty tried to boot my Debian lenny distro on a newer Intel
Nehalem box using Debian Lenny's default xen kernel
(2.6.26-2-xen-686), and it crashed during boot.  Full log attached,
but the key info is here:

I tried doing a "binary search" to see where this was introduced, but
it fails the same way all the way back to c/s 20000.

The same kernel/hypervisor combination boots fine on a different box I have.

 -George

(XEN) ----[ Xen-4.0.0-rc4  x86_64  debug=n  Tainted:    C ]----
(XEN) CPU:    15
(XEN) RIP:    e008:[<ffff82c4801535a9>] pci_enable_msi+0x4c9/0x580
(XEN) RFLAGS: 0000000000010282   CONTEXT: hypervisor
(XEN) rax: ffff82c3ffeb6141   rbx: 0000000000000000   rcx: ffff830828b0e690
(XEN) rdx: ffff830828b0e718   rsi: ffff8300bf6975b0   rdi: ffff830828b0e6e0
(XEN) rbp: ffff83082cd7fec8   rsp: ffff83082cd7fd88   r8:  0000000000000005
(XEN) r9:  ffff830828b0e700   r10: 00000000000000a8   r11: 0000000000000040
(XEN) r12: ffff830828b0e710   r13: ffff830828b0e670   r14: ffff83082cd7fe38
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 000000043fdcf000   cr2: ffff82c3ffeb614d
(XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff83082cd7fd88:
(XEN)    0000000000000246 ffff830828b0e6e0 0000000080000000 0000000100000000
(XEN)    3408000000000000 0000000200000000 000f5861e4a00100 0000000000000141
(XEN)    ffff83082cd71ec8 ffff83082cd7fec8 0000000000000136 ffff83082cd60000
(XEN)    0000000000000038 00000000ffffffed 0000000000000000 ffff82c480154832
(XEN)    00000000000004d8 0000000000000038 00000000000000e0 ffff83083fd81c80
(XEN)    ffff830828b0e670 00000000f5861e0c 0000000000000000 ffff83082cd60000
(XEN)    ffff83082cd400f0 00000000f5861e0c 0000000000000136 0000000000000038
(XEN)    ffff83082cd7fec8 ffff82c4801ede5f 7265646e776f206f ffff82c48024c080
(XEN)    ffff83082cd60180 ffff83082cd7fe98 0000000000007ff0 ffffffffffffffff
(XEN)    0000000800000000 0000000100000000 ffff8308f5861e4a ffff82c4802eaa80
(XEN)    0000000800000000 0000000000000038 f5861e4a00000001 000000000000000f
(XEN)    ffffffffffffffff ffff8300bf2e8000 0000000000000035 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 ffff82c4801ef863
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000035 000000000000000d 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000021 00000000f5861e0c
(XEN)    00000000c033741f 00000000ffffffff 0000000000000000 0000010000000000
(XEN)    00000000c0101427 0000000000000061 0000000000000286 00000000f5861e08
(XEN)    0000000000000069 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 000000000000000f ffff8300bf2e8000
(XEN) Xen call trace:
(XEN)    [<ffff82c4801535a9>] pci_enable_msi+0x4c9/0x580
(XEN)    [<ffff82c480154832>] map_domain_pirq+0x242/0x2f0
(XEN)    [<ffff82c4801ede5f>] compat_physdev_op+0xc8f/0x1010
(XEN)    [<ffff82c4801ef863>] compat_hypercall+0x83/0x90
(XEN)
(XEN) Pagetable walk from ffff82c3ffeb614d:
(XEN)  L4[0x105] = 00000000bf4e2027 5555555555555555
(XEN)  L3[0x10f] = 00000000bf698063 5555555555555555
(XEN)  L2[0x1ff] = 00000000bf697063 5555555555555555
(XEN)  L1[0x0b6] = f5861e4a00100173 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 15:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=000b]
(XEN) Faulting linear address: ffff82c3ffeb614d
(XEN) ****************************************

[-- Attachment #2: deb-dom0-crash.txt --]
[-- Type: text/plain, Size: 56361 bytes --]

 __  __            _  _    ___   ___              _  _   
 \ \/ /___ _ __   | || |  / _ \ / _ \    _ __ ___| || |  
  \  // _ \ '_ \  | || |_| | | | | | |__| '__/ __| || |_ 
  /  \  __/ | | | |__   _| |_| | |_| |__| | | (__|__   _|
 /_/\_\___|_| |_|    |_|(_)___(_)___/   |_|  \___|  |_|  
                                                         
(XEN) Xen version 4.0.0-rc4 (dunlapg@(none)) (gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)) Wed Feb 24 13:31:53 EST 2010
(XEN) Latest ChangeSet: unavailable
(XEN) Console output is synchronous.
(XEN) Command line: sched=credit2 watchdog com1=115200,8n1 console=com1 sync_console console_to_ring tmem=0 loglvl=all guest_loglvl=all 
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 00000000000a0000 (usable)
(XEN)  0000000000100000 - 00000000bf699000 (usable)
(XEN)  00000000bf699000 - 00000000bf6af000 (reserved)
(XEN)  00000000bf6af000 - 00000000bf6ce000 (ACPI data)
(XEN)  00000000bf6ce000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fe000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000840000000 (usable)
(XEN) ACPI: RSDP 000F1630, 0024 (r2 DELL  )
(XEN) ACPI: XSDT 000F1734, 009C (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: FACP BF6C3F9C, 00F4 (r3 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: DSDT BF6AF000, 320F (r1 DELL   PE_SC3          1 INTL 20050624)
(XEN) ACPI: FACS BF6C6000, 0040
(XEN) ACPI: APIC BF6C3478, 015E (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SPCR BF6C35D8, 0050 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: HPET BF6C362C, 0038 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: DMAR BF6C3668, 01C0 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: MCFG BF6C38C4, 003C (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: WD__ BF6C3904, 0134 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SLIC BF6C3A3C, 0024 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: ERST BF6B2390, 0270 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: HEST BF6B2600, 027C (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: BERT BF6B2210, 0030 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: EINJ BF6B2240, 0150 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SRAT BF6C3BC0, 0370 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: TCPA BF6C3F34, 0064 (r2 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SSDT BF6C7000, 4194 (r1  INTEL PPM RCM  80000001 INTL 20061109)
(XEN) System RAM: 32736MB (33522460kB)
(XEN) SRAT: PXM 1 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 0 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 2 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 4 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 22 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 6 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 1 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 19 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 3 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 21 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 5 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 23 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 7 -> Node 1
(XEN) SRAT: Node 1 PXM 2 0-c0000000
(XEN) SRAT: Node 1 PXM 2 100000000-440000000
(XEN) SRAT: Node 0 PXM 1 440000000-840000000
(XEN) NUMA: Allocated memnodemap from 83fdfe000 - 83fdff000
(XEN) NUMA: Using 18 for the hash shift.
(XEN) Domain heap initialised DMA width 32 bits
(XEN) found SMP MP-table at 000fe710
(XEN) DMI 2.6 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI:                  wakeup_vec[bf6c600c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x10] enabled)
(XEN) Processor #16 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x00] enabled)
(XEN) Processor #0 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x12] enabled)
(XEN) Processor #18 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x02] enabled)
(XEN) Processor #2 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
(XEN) Processor #20 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x04] enabled)
(XEN) Processor #4 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x16] enabled)
(XEN) Processor #22 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x06] enabled)
(XEN) Processor #6 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x11] enabled)
(XEN) Processor #17 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x01] enabled)
(XEN) Processor #1 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x13] enabled)
(XEN) Processor #19 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x03] enabled)
(XEN) Processor #3 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x15] enabled)
(XEN) Processor #21 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x05] enabled)
(XEN) Processor #5 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x17] enabled)
(XEN) Processor #23 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x07] enabled)
(XEN) Processor #7 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x30] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x31] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x32] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x33] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x34] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x35] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x36] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x37] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x19] lapic_id[0x38] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x39] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x3a] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x3b] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x3c] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x3d] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x3e] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x20] lapic_id[0x3f] disabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec80000] gsi_base[32])
(XEN) IOAPIC[1]: apic_id 1, version 32, address 0xfec80000, GSI 32-55
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) [VT-D]dmar.c:637: Host address width 40
(XEN) [VT-D]dmar.c:646: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:379:   dmaru->address = fed90000
(XEN) [VT-D]dmar.c:336:   IOAPIC: 0:1e.1
(XEN) [VT-D]dmar.c:336:   IOAPIC: 0:13.0
(XEN) [VT-D]dmar.c:391:   flags: INCLUDE_ALL
(XEN) [VT-D]dmar.c:650: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:331:   endpoint: 0:1a.7
(XEN) [VT-D]dmar.c:331:   endpoint: 0:1d.7
(XEN) [VT-D]dmar.c:540:   RMRR region: base_addr bf7c8000 end_address bf7dffff
(XEN) [VT-D]dmar.c:650: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:331:   endpoint: 0:1a.0
(XEN) [VT-D]dmar.c:331:   endpoint: 0:1a.1
(XEN) [VT-D]dmar.c:331:   endpoint: 0:1a.2
(XEN) [VT-D]dmar.c:331:   endpoint: 0:1d.0
(XEN) [VT-D]dmar.c:331:   endpoint: 0:1d.1
(XEN) [VT-D]dmar.c:331:   endpoint: 0:1d.2
(XEN) [VT-D]dmar.c:540:   RMRR region: base_addr bf7b1000 end_address bf7bffff
(XEN) [VT-D]dmar.c:650: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:331:   endpoint: 0:1a.0
(XEN) [VT-D]dmar.c:540:   RMRR region: base_addr bf7a1000 end_address bf7a1fff
(XEN) [VT-D]dmar.c:650: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:331:   endpoint: 0:1a.1
(XEN) [VT-D]dmar.c:540:   RMRR region: base_addr bf7a3000 end_address bf7a3fff
(XEN) [VT-D]dmar.c:650: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:331:   endpoint: 0:1d.0
(XEN) [VT-D]dmar.c:540:   RMRR region: base_addr bf7a5000 end_address bf7a5fff
(XEN) [VT-D]dmar.c:650: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:331:   endpoint: 0:1d.1
(XEN) [VT-D]dmar.c:540:   RMRR region: base_addr bf7a7000 end_address bf7a7fff
(XEN) [VT-D]dmar.c:650: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:331:   endpoint: 0:1a.7
(XEN) [VT-D]dmar.c:540:   RMRR region: base_addr bf7c0000 end_address bf7c0fff
(XEN) [VT-D]dmar.c:650: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:331:   endpoint: 0:1d.7
(XEN) [VT-D]dmar.c:540:   RMRR region: base_addr bf7c2000 end_address bf7c2fff
(XEN) [VT-D]dmar.c:654: found ACPI_DMAR_ATSR:
(XEN) [VT-D]dmar.c:564:   atsru->all_ports: 0
(XEN) [VT-D]dmar.c:319:   bridge: 0:1.0  start = 0 sec = 1  sub = 1
(XEN) [VT-D]dmar.c:319:   bridge: 0:3.0  start = 0 sec = 2  sub = 2
(XEN) [VT-D]dmar.c:319:   bridge: 0:4.0  start = 0 sec = 3  sub = 3
(XEN) [VT-D]dmar.c:319:   bridge: 0:5.0  start = 0 sec = 4  sub = 4
(XEN) [VT-D]dmar.c:319:   bridge: 0:6.0  start = 0 sec = 5  sub = 8
(XEN) [VT-D]dmar.c:319:   bridge: 0:7.0  start = 0 sec = 9  sub = 9
(XEN) [VT-D]dmar.c:319:   bridge: 0:9.0  start = 0 sec = a  sub = a
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Could not find scheduler: credit2
(XEN) Using scheduler: Simple EDF Scheduler (sedf)
(XEN) Initializing CPU#0
(XEN) Detected 2261.060 MHz processor.
(XEN) Initing memory sharing.
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 1
(XEN) CPU: Processor Core ID: 0
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN) HVM: ASIDs enabled. 
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Intel machine check reporting enabled on CPU#0.
(XEN) CPU0: Thermal monitoring enabled (TM1)
(XEN) [VT-D]iommu.c:1068: drhd->address = fed90000
(XEN) [VT-D]iommu.c:1069: iommu->reg = ffff82c3fff57000
(XEN) Intel VT-d Snoop Control supported.
(XEN) Intel VT-d DMA Passthrough not supported.
(XEN) Intel VT-d Queued Invalidation supported.
(XEN) Intel VT-d Interrupt Remapping supported.
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled
(XEN) CPU0: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Booting processor 1/0 eip 88000
(XEN) Initializing CPU#1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 0
(XEN) HVM: ASIDs enabled. 
(XEN) Intel machine check reporting enabled on CPU#1.
(XEN) CPU1: Thermal monitoring enabled (TM1)
(XEN) CPU1: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Booting processor 2/18 eip 88000
(XEN) Initializing CPU#2
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 1
(XEN) CPU: Processor Core ID: 1
(XEN) HVM: ASIDs enabled. 
(XEN) Intel machine check reporting enabled on CPU#2.
(XEN) CPU2: Thermal monitoring enabled (TM1)
(XEN) CPU2: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Booting processor 3/2 eip 88000
(XEN) Initializing CPU#3
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) HVM: ASIDs enabled. 
(XEN) Intel machine check reporting enabled on CPU#3.
(XEN) CPU3: Thermal monitoring enabled (TM1)
(XEN) CPU3: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Booting processor 4/20 eip 88000
(XEN) Initializing CPU#4
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 1
(XEN) CPU: Processor Core ID: 2
(XEN) HVM: ASIDs enabled. 
(XEN) Intel machine check reporting enabled on CPU#4.
(XEN) CPU4: Thermal monitoring enabled (TM1)
(XEN) CPU4: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Booting processor 5/4 eip 88000
(XEN) Initializing CPU#5
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 2
(XEN) HVM: ASIDs enabled. 
(XEN) Intel machine check reporting enabled on CPU#5.
(XEN) CPU5: Thermal monitoring enabled (TM1)
(XEN) CPU5: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Booting processor 6/22 eip 88000
(XEN) Initializing CPU#6
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 1
(XEN) CPU: Processor Core ID: 3
(XEN) HVM: ASIDs enabled. 
(XEN) Intel machine check reporting enabled on CPU#6.
(XEN) CPU6: Thermal monitoring enabled (TM1)
(XEN) CPU6: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Booting processor 7/6 eip 88000
(XEN) Initializing CPU#7
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 3
(XEN) HVM: ASIDs enabled. 
(XEN) Intel machine check reporting enabled on CPU#7.
(XEN) CPU7: Thermal monitoring enabled (TM1)
(XEN) CPU7: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Booting processor 8/17 eip 88000
(XEN) Initializing CPU#8
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 1
(XEN) CPU: Processor Core ID: 0
(XEN) HVM: ASIDs enabled. 
(XEN) Intel machine check reporting enabled on CPU#8.
(XEN) CPU8: Thermal monitoring enabled (TM1)
(XEN) CPU8: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Booting processor 9/1 eip 88000
(XEN) Initializing CPU#9
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 0
(XEN) HVM: ASIDs enabled. 
(XEN) Intel machine check reporting enabled on CPU#9.
(XEN) CPU9: Thermal monitoring enabled (TM1)
(XEN) CPU9: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Booting processor 10/19 eip 88000
(XEN) Initializing CPU#10
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 1
(XEN) CPU: Processor Core ID: 1
(XEN) HVM: ASIDs enabled. 
(XEN) Intel machine check reporting enabled on CPU#10.
(XEN) CPU10: Thermal monitoring enabled (TM1)
(XEN) CPU10: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Booting processor 11/3 eip 88000
(XEN) Initializing CPU#11
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) HVM: ASIDs enabled. 
(XEN) Intel machine check reporting enabled on CPU#11.
(XEN) CPU11: Thermal monitoring enabled (TM1)
(XEN) CPU11: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Booting processor 12/21 eip 88000
(XEN) Initializing CPU#12
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 1
(XEN) CPU: Processor Core ID: 2
(XEN) HVM: ASIDs enabled. 
(XEN) Intel machine check reporting enabled on CPU#12.
(XEN) CPU12: Thermal monitoring enabled (TM1)
(XEN) CPU12: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Booting processor 13/5 eip 88000
(XEN) Initializing CPU#13
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 2
(XEN) HVM: ASIDs enabled. 
(XEN) Intel machine check reporting enabled on CPU#13.
(XEN) CPU13: Thermal monitoring enabled (TM1)
(XEN) CPU13: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Booting processor 14/23 eip 88000
(XEN) Initializing CPU#14
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 1
(XEN) CPU: Processor Core ID: 3
(XEN) HVM: ASIDs enabled. 
(XEN) Intel machine check reporting enabled on CPU#14.
(XEN) CPU14: Thermal monitoring enabled (TM1)
(XEN) CPU14: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Booting processor 15/7 eip 88000
(XEN) Initializing CPU#15
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 3
(XEN) HVM: ASIDs enabled. 
(XEN) Intel machine check reporting enabled on CPU#15.
(XEN) CPU15: Thermal monitoring enabled (TM1)
(XEN) CPU15: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz stepping 05
(XEN) Total of 16 processors activated.
(XEN) Testing NMI watchdog --- CPU#0 okay. CPU#1 okay. CPU#2 okay. CPU#3 okay. CPU#4 okay. CPU#5 okay. CPU#6 okay. CPU#7 okay. CPU#8 okay. CPU#9 okay. CPU#10 okay. CPU#11 okay. CPU#12 okay. CPU#13 okay. CPU#14 okay. CPU#15 okay. 
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) TSC is reliable, synchronization unnecessary
(XEN) Platform timer is 14.318MHz HPET
XEN) CPU 0 APIC 16 -> Node 0
(XEN) CPU 1 APIC 0 -> Node 1
(XEN) microcode.c:73:d32767 microcode: CPU1 resumed
(XEN) microcode.c:73:d32767 microcode: CPU2 resumed
(XEN) CPU 2 APIC 18 -> Node 0
(XEN) CPU 3 APIC 2 -> Node 1
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) microcode.c:73:d32767 microcode: CPU4 resumed
(XEN) CPU 4 APIC 20 -> Node 0
(XEN) CPU 5 APIC 4 -> Node 1
(XEN) microcode.c:73:d32767 microcode: CPU5 resumed
(XEN) microcode.c:73:d32767 microcode: CPU6 resumed
(XEN) CPU 6 APIC 22 -> Node 0
(XEN) CPU 7 APIC 6 -> Node 1
(XEN) microcode.c:73:d32767 microcode: CPU7 resumed
(XEN) CPU 8 APIC 17 -> Node 0
(XEN) microcode.c:73:d32767 microcode: CPU8 resumed
(XEN) CPU 9 APIC 1 -> Node 1
(XEN) microcode.c:73:d32767 microcode: CPU9 resumed
(XEN) microcode.c:73:d32767 microcode: CPU10 resumed
(XEN) CPU 10 APIC 19 -> Node 0
(XEN) CPU 11 APIC 3 -> Node 1
(XEN) microcode.c:73:d32767 microcode: CPU11 resumed
(XEN) microcode.c:73:d32767 microcode: CPU12 resumed
(XEN) CPU 12 APIC 21 -> Node 0
(XEN) CPU 13 APIC 5 -> Node 1
(XEN) microcode.c:73:d32767 microcode: CPU13 resumed
(XEN) microcode.c:73:d32767 microcode: CPU14 resumed
(XEN) CPU 14 APIC 23 -> Node 0
(XEN) CPU 15 APIC 7 -> Node 1
(XEN) microcode.c:73:d32767 microcode: CPU15 resumed
(XEN) Brought up 16 CPUs
(XEN) Turbo Mode detected!
(XEN) HPET: 4 timers in total, 0 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) [VT-D]iommu.c:1305:d32767 domain_context_mapping:PCIe: bdf = 0:0.0
(XEN) [VT-D]iommu.c:1305:d32767 domain_context_mapping:PCIe: bdf = 0:14.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:14.0:  no extended config
(XEN) [VT-D]iommu.c:1305:d32767 domain_context_mapping:PCIe: bdf = 0:14.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:14.1:  no extended config
(XEN) [VT-D]iommu.c:1305:d32767 domain_context_mapping:PCIe: bdf = 0:14.2
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:14.2:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = 0:1a.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1a.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = 0:1a.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1a.1:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = 0:1a.7
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1a.7:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1d.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = 0:1d.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1d.1:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = 0:1d.7
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1d.7:  no extended config
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1e.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = 0:1f.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1f.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = 0:1f.2
(XEN) [VT-D]iommu.c:1305:d32767 domain_context_mapping:PCIe: bdf = 1:0.0
(XEN) [VT-D]iommu.c:1305:d32767 domain_context_mapping:PCIe: bdf = 1:0.1
(XEN) [VT-D]iommu.c:1305:d32767 domain_context_mapping:PCIe: bdf = 2:0.0
(XEN) [VT-D]iommu.c:1305:d32767 domain_context_mapping:PCIe: bdf = 2:0.1
(XEN) [VT-D]iommu.c:1305:d32767 domain_context_mapping:PCIe: bdf = 3:0.0
(XEN) [VT-D]iommu.c:1305:d32767 domain_context_mapping:PCIe: bdf = 7:0.0
(XEN) [VT-D]iommu.c:1305:d32767 domain_context_mapping:PCIe: bdf = 7:0.1
(XEN) [VT-D]iommu.c:1305:d32767 domain_context_mapping:PCIe: bdf = 8:0.0
(XEN) [VT-D]iommu.c:1305:d32767 domain_context_mapping:PCIe: bdf = 8:0.1
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = b:3.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:b:3.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = b:3.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:b:3.1:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = b:3.2
(XEN) [VT-D]mmconfig-shared.c:460: next cap:b:3.2:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = b:3.3
(XEN) [VT-D]mmconfig-shared.c:460: next cap:b:3.3:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = b:3.4
(XEN) [VT-D]mmconfig-shared.c:460: next cap:b:3.4:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = b:3.5
(XEN) [VT-D]mmconfig-shared.c:460: next cap:b:3.5:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = b:3.6
(XEN) [VT-D]mmconfig-shared.c:460: next cap:b:3.6:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = b:3.7
(XEN) [VT-D]mmconfig-shared.c:460: next cap:b:3.7:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:0.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:0.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:0.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:0.1:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:2.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:2.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:2.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:2.1:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:2.4
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:2.4:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:2.5
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:2.5:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:3.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:3.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:3.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:3.1:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:3.2
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:3.2:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:3.4
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:3.4:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:4.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:4.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:4.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:4.1:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:4.2
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:4.2:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:4.3
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:4.3:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:5.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:5.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:5.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:5.1:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:5.2
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:5.2:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:5.3
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:5.3:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:6.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:6.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:6.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:6.1:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:6.2
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:6.2:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = fe:6.3
(XEN) [VT-D]mmconfig-shared.c:460: next cap:fe:6.3:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:0.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:0.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:0.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:0.1:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:2.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:2.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:2.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:2.1:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:2.4
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:2.4:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:2.5
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:2.5:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:3.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:3.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:3.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:3.1:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:3.2
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:3.2:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:3.4
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:3.4:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:4.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:4.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:4.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:4.1:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:4.2
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:4.2:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:4.3
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:4.3:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:5.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:5.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:5.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:5.1:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:5.2
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:5.2:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:5.3
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:5.3:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:6.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:6.0:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:6.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:6.1:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:6.2
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:6.2:  no extended config
(XEN) [VT-D]iommu.c:1312:d32767 domain_context_mapping:PCI: bdf = ff:6.3
(XEN) [VT-D]mmconfig-shared.c:460: next cap:ff:6.3:  no extended config
(XEN) [VT-D]iommu.c:690: iommu_enable_translation: iommu->reg = ffff82c3fff57000
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x100000 -> 0x42e000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000824000000->0000000828000000 (8227958 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 00000000c0100000->00000000c042e000
(XEN)  Init. ramdisk: 00000000c042e000->00000000c1427200
(XEN)  Phys-Mach map: 00000000c1428000->00000000c339b1d8
(XEN)  Start info:    00000000c339c000->00000000c339c4b4
(XEN)  Page tables:   00000000c339d000->00000000c33bf000
(XEN)  Boot stack:    00000000c33bf000->00000000c33c0000
(XEN)  TOTAL:         00000000c0000000->00000000c3800000
(XEN)  ENTRY ADDRESS: 00000000c0100000
(XEN) Dom0 has maximum 16 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1... 
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 152kB init memory.
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.26-2-xen-686 (Debian 2.6.26-19lenny2) (dannf@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Wed Nov 4 23:23:33 UTC 2009
[    0.000000] Reserving virtual address space above 0xfdc00000
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000007dd476000 (usable)
[    0.000000] console [earlyser0] enabled
[    0.000000] 31352MB HIGHMEM available.
[    0.000000] 860MB LOWMEM available.
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA             0 ->     4096
[    0.000000]   Normal       4096 ->   220160
[    0.000000]   HighMem    220160 ->  8246390
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0:        0 ->  8246390
[    0.000000] found SMP MP-table at [fda54710] 000fe710
[    0.000000] DMI 2.6 present.
[    0.000000] ACPI: RSDP 000F1630, 0024 (r2 DELL  )
[    0.000000] ACPI: XSDT 000F1734, 009C (r1 DELL   PE_SC3          1 DELL        1)
[    0.000000] ACPI: FACP BF6C3F9C, 00F4 (r3 DELL   PE_SC3          1 DELL        1)
[    0.000000] ACPI: DSDT BF6AF000, 320F (r1 DELL   PE_SC3          1 INTL 20050624)
[    0.000000] ACPI: FACS BF6C6000, 0040
[    0.000000] ACPI: APIC BF6C3478, 015E (r1 DELL   PE_SC3          1 DELL        1)
[    0.000000] ACPI: SPCR BF6C35D8, 0050 (r1 DELL   PE_SC3          1 DELL        1)
[    0.000000] ACPI: HPET BF6C362C, 0038 (r1 DELL   PE_SC3          1 DELL        1)
[    0.000000] ACPI:      BF6C3668, 01C0 (r1 DELL   PE_SC3          1 DELL        1)
[    0.000000] ACPI: MCFG BF6C38C4, 003C (r1 DELL   PE_SC3          1 DELL        1)
[    0.000000] ACPI: WD__ BF6C3904, 0134 (r1 DELL   PE_SC3          1 DELL        1)
[    0.000000] ACPI: SLIC BF6C3A3C, 0024 (r1 DELL   PE_SC3          1 DELL        1)
[    0.000000] ACPI: ERST BF6B2390, 0270 (r1 DELL   PE_SC3          1 DELL        1)
[    0.000000] ACPI: HEST BF6B2600, 027C (r1 DELL   PE_SC3          1 DELL        1)
[    0.000000] ACPI: BERT BF6B2210, 0030 (r1 DELL   PE_SC3          1 DELL        1)
[    0.000000] ACPI: EINJ BF6B2240, 0150 (r1 DELL   PE_SC3          1 DELL        1)
[    0.000000] ACPI: SRAT BF6C3BC0, 0370 (r1 DELL   PE_SC3          1 DELL        1)
[    0.000000] ACPI: TCPA BF6C3F34, 0064 (r2 DELL   PE_SC3          1 DELL        1)
[    0.000000] ACPI: SSDT BF6C7000, 4194 (r1  INTEL PPM RCM  80000001 INTL 20061109)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x10] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x12] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x16] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x11] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x13] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x15] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x05] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x17] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x07] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x30] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x31] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x32] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x33] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x34] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x35] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x36] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x37] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x19] lapic_id[0x38] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x39] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x3a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x3b] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x3c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x3d] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x3e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x20] lapic_id[0x3f] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec80000] gsi_base[32])
[    0.000000] IOAPIC[1]: apic_id 1, version 32, address 0xfec80000, GSI 32-55
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] Allocating PCI resources starting at c2000000 (gap: c0000000:20000000)
[    0.000000] PERCPU: Allocating 28552 bytes of per cpu data
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8181965
[    0.000000] Kernel command line: root=/dev/sda1 ro console=hvc0 earlyprintk=xen
[    0.000000] Enabling fast FPU save and restore... done.
[    0.000000] Enabling unmasked SIMD FPU exception support... done.
[    0.000000] Initializing CPU#0
[    0.000000] PID hash table entries: 4096 (order: 12, 16384 bytes)
[    0.000000] Extended CMOS year: 2000
[    0.000000] Xen reported: 2261.060 MHz processor.
[    0.004000] Console: colour VGA+ 80x25
[    0.004000] console handover: boot [earlyser0] -> real [hvc0]
[    0.004000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.004000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.004000] Software IO TLB enabled: 
[    0.004000]  Aperture:     64 megabytes
[    0.004000]  Kernel range: d4f94000 - d8f94000
[    0.004000]  Address size: 27 bits
[    0.004000] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    0.004000] Memory: 32597796k/32985560k available (1845k kernel code, 378660k reserved, 740k data, 196k init, 32104920k highmem)
[    0.004000] virtual kernel memory layout:
[    0.004000]     fixmap  : 0xfd955000 - 0xfdbff000   (2728 kB)
[    0.004000]     pkmap   : 0xfd400000 - 0xfd600000   (2048 kB)
[    0.004000]     vmalloc : 0xf6800000 - 0xfd3fe000   ( 107 MB)
[    0.004000]     lowmem  : 0xc0000000 - 0xf5c00000   ( 860 MB)
[    0.004000]       .init : 0xc038f000 - 0xc03c0000   ( 196 kB)
[    0.004000]       .data : 0xc02cd517 - 0xc03868a0   ( 740 kB)
[    0.004000]       .text : 0xc0100000 - 0xc02cd517   (1845 kB)
[    0.004000] Checking if this processor honours the WP bit even in supervisor mode...Ok.
[    1.619972] Calibrating delay using timer specific routine.. 4523.98 BogoMIPS (lpj=9047971)
[    1.627972] Security Framework initialized
[    1.632031] SELinux:  Disabled at boot.
[    1.635840] Capability LSM initialized
[    1.639987] Mount-cache hash table entries: 512
[    1.644585] Initializing cgroup subsys ns
[    1.647977] Initializing cgroup subsys cpuacct
[    1.652400] Initializing cgroup subsys devices
[    1.656837] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.661495] CPU: L2 cache: 256K
[    1.663980] CPU: L3 cache: 8192K
[    1.667989] Checking 'hlt' instruction... OK.
[    1.672530] SMP alternatives: switching to UP code
[    1.689717] ACPI: Core revision 20080321
[    1.699987] ENABLING IO-APIC IRQs
(XEN) io_apic.c:2291: 
(XEN) ioapic_guest_write: apic=0, pin=2, irq=0
(XEN) ioapic_guest_write: new_entry=00000000
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
(XEN) io_apic.c:2291: 
(XEN) ioapic_guest_write: apic=0, pin=4, irq=4
(XEN) ioapic_guest_write: new_entry=00000004
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
[    1.737478] SMP alternatives: switching to SMP code
[    1.754177] Initializing CPU#1
[    1.754177] Initializing CPU#2
[    1.754177] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.754177] CPU: L2 cache: 256K
[    1.754177] CPU: L3 cache: 8192K
[    1.758072] Initializing CPU#3
[    1.758072] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.758072] CPU: L2 cache: 256K
[    1.758072] CPU: L3 cache: 8192K
[    1.758072] Initializing CPU#4
[    1.758072] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.758072] CPU: L2 cache: 256K
[    1.758072] CPU: L3 cache: 8192K
[    1.758173] Initializing CPU#5
[    1.758173] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.758173] CPU: L2 cache: 256K
[    1.758173] CPU: L3 cache: 8192K
[    1.758274] Initializing CPU#6
[    1.758274] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.758274] CPU: L2 cache: 256K
[    1.758274] CPU: L3 cache: 8192K
[    1.758281] Initializing CPU#7
[    1.758281] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.758281] CPU: L2 cache: 256K
[    1.758281] CPU: L3 cache: 8192K
[    1.758377] Initializing CPU#8
[    1.758377] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.758377] CPU: L2 cache: 256K
[    1.758377] CPU: L3 cache: 8192K
[    1.758482] Initializing CPU#9
[    1.758482] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.758482] CPU: L2 cache: 256K
[    1.758482] CPU: L3 cache: 8192K
[    1.758585] Initializing CPU#10
[    1.758585] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.758585] CPU: L2 cache: 256K
[    1.758585] CPU: L3 cache: 8192K
[    1.758690] Initializing CPU#11
[    1.758690] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.758690] CPU: L2 cache: 256K
[    1.758690] CPU: L3 cache: 8192K
[    1.758794] Initializing CPU#12
[    1.758794] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.758794] CPU: L2 cache: 256K
[    1.758794] CPU: L3 cache: 8192K
[    1.758888] Initializing CPU#13
[    1.758888] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.758888] CPU: L2 cache: 256K
[    1.758888] CPU: L3 cache: 8192K
[    1.758992] Initializing CPU#14
[    1.758992] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.758992] CPU: L2 cache: 256K
[    1.758992] CPU: L3 cache: 8192K
[    1.759093] Brought up 16 CPUs
[    1.759093] Initializing CPU#15
[    1.759093] CPU: L1 I cache: 32K<7> domain 0: , L1 D cache: 32K
[    1.759093] span 0-15
[    1.759093] CPU: L2 cache: 256K
[    1.759093]  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0
[    1.779015] net_namespace: 660 bytes
[    1.754177] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.754177] CPU: L2 cache: 256K
[    1.754177] CPU: L3 cache: 8192K
[    2.006751] NET: Registered protocol family 16
[    2.022543] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    2.030617] ACPI: bus type pci registered
[    2.038622] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
[    2.046261] PCI: MCFG area at e0000000 reserved in E820
[    2.053402] PCI: Using MMCONFIG for extended config space
[    2.058786] PCI: Using configuration type 1 for base access
[    2.064765] Setting up standard PCI resources
[    2.088460] ACPI: BIOS _OSI(Linux) query ignored
[    2.093517] ACPI: DMI System Vendor: Dell Inc.
[    2.097967] ACPI: DMI Product Name: PowerEdge R710
[    2.102738] ACPI: DMI Product Version: 
[    2.106502] ACPI: DMI Board Name: 0N047H
[    2.110523] ACPI: DMI BIOS Vendor: Dell Inc.
[    2.115228] ACPI: DMI BIOS Date: 05/08/2009
[    2.119470] ACPI: Please send DMI info above to linux-acpi@vger.kernel.org
[    2.127070] ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org
[    2.136455] ACPI: Interpreter enabled
[    2.140067] ACPI: (supports S0 S5)
[    2.143586] ACPI: Using IOAPIC for interrupt routing
[    2.160634] ACPI: PCI Root Bridge [PCI0] (0000:00)
[    2.168253] pci 0000:00:1f.0: quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO
[    2.176266] pci 0000:00:1f.0: quirk: region 0880-08bf claimed by ICH6 GPIO
[    2.185988] PCI: Transparent bridge - 0000:00:1e.0
[    2.210228] ACPI: PCI Interrupt Link [LK00] (IRQs 3 4 5 6 7 10 11 14 *15)
[    2.216948] ACPI: PCI Interrupt Link [LK01] (IRQs 3 4 5 6 7 10 11 *14 15)
[    2.224050] ACPI: PCI Interrupt Link [LK02] (IRQs 3 4 5 6 7 10 *11 14 15)
[    2.232457] ACPI: PCI Interrupt Link [LK03] (IRQs 3 4 5 6 7 *10 11 14 15)
[    2.239136] ACPI: PCI Interrupt Link [LK04] (IRQs 3 4 *5 6 7 10 11 14 15)
[    2.245904] ACPI: PCI Interrupt Link [LK05] (IRQs 3 4 5 *6 7 10 11 14 15)
[    2.254305] ACPI: PCI Interrupt Link [LK06] (IRQs 3 4 5 6 7 10 11 14 15) *0, disabled.
[    2.262625] ACPI: PCI Interrupt Link [LK07] (IRQs 3 4 5 6 7 10 11 *14 15)
[    2.270918] ACPI Warning (tbutils-0217): Incorrect checksum in table [    ] - 6B, should be AF [20080321]
[    2.281497] Linux Plug and Play Support v0.97 (c) Adam Belay
[    2.287761] pnp: PnP ACPI init
[    2.291199] ACPI: bus type pnp registered
(XEN) io_apic.c:2291: 
(XEN) ioapic_guest_write: apic=0, pin=4, irq=4
(XEN) ioapic_guest_write: new_entry=00010004
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
[    2.323028] pnp: PnP ACPI: found 13 devices
[    2.327091] ACPI: ACPI bus type pnp unregistered
[    2.331938] xen_mem: Initialising balloon driver.
[    2.346665] PCI: Using ACPI for IRQ routing
[    2.360566] ACPI: RTC can wake from S4
[    2.364763] system 00:07: ioport range 0x800-0x87f has been reserved
[    2.376987] system 00:07: ioport range 0x880-0x8ff could not be reserved
[    2.383659] system 00:07: ioport range 0x900-0x91f has been reserved
[    2.391659] system 00:07: ioport range 0x920-0x923 has been reserved
[    2.397987] system 00:07: ioport range 0x924-0x924 has been reserved
[    2.405079] system 00:07: ioport range 0xc00-0xc7f has been reserved
[    2.411468] system 00:07: ioport range 0xca0-0xca7 has been reserved
[    2.417791] system 00:07: ioport range 0xca9-0xcab has been reserved
[    2.424946] system 00:07: ioport range 0xcad-0xcaf has been reserved
[    2.431278] system 00:08: ioport range 0xca8-0xca8 has been reserved
[    2.437599] system 00:08: ioport range 0xcac-0xcac has been reserved
[    2.444674] system 00:0a: iomem range 0xe0000000-0xefffffff could not be reserved
[    2.452187] system 00:0c: iomem range 0xfed90000-0xfed91fff could not be reserved
(XEN) PCI add device 00:00.0
(XEN) [VT-D]iommu.c:1431:d0 domain_context_unmap:PCIe: bdf = 0:0.0
(XEN) PCI remove device 00:00.0
(XEN) PCI add device 00:01.0
(XEN) PCI remove device 00:01.0
(XEN) PCI add device 00:03.0
(XEN) PCI remove device 00:03.0
(XEN) PCI add device 00:04.0
(XEN) PCI remove device 00:04.0
(XEN) PCI add device 00:05.0
(XEN) PCI remove device 00:05.0
(XEN) PCI add device 00:06.0
(XEN) PCI remove device 00:06.0
(XEN) PCI add device 00:07.0
(XEN) PCI remove device 00:07.0
(XEN) PCI add device 00:09.0
(XEN) PCI remove device 00:09.0
(XEN) PCI add device 00:14.0
(XEN) [VT-D]iommu.c:1431:d0 domain_context_unmap:PCIe: bdf = 0:14.0
(XEN) PCI remove device 00:14.0
(XEN) PCI add device 00:14.1
(XEN) [VT-D]iommu.c:1431:d0 domain_context_unmap:PCIe: bdf = 0:14.1
(XEN) PCI remove device 00:14.1
(XEN) PCI add device 00:14.2
(XEN) [VT-D]iommu.c:1431:d0 domain_context_unmap:PCIe: bdf = 0:14.2
(XEN) PCI remove device 00:14.2
(XEN) PCI add device 00:1a.0
(XEN) PCI remove device 00:1a.0
(XEN) PCI add device 00:1a.1
(XEN) PCI remove device 00:1a.1
(XEN) PCI add device 00:1a.7
(XEN) PCI remove device 00:1a.7
(XEN) PCI add device 00:1d.0
(XEN) PCI remove device 00:1d.0
(XEN) PCI add device 00:1d.1
(XEN) PCI remove device 00:1d.1
(XEN) PCI add device 00:1d.7
(XEN) PCI remove device 00:1d.7
(XEN) PCI add device 00:1e.0
(XEN) PCI remove device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) [VT-D]iommu.c:1438:d0 domain_context_unmap:PCI: bdf = 0:1f.0
(XEN) PCI remove device 00:1f.0
(XEN) PCI add device 00:1f.2
(XEN) [VT-D]iommu.c:1438:d0 domain_context_unmap:PCI: bdf = 0:1f.2
(XEN) PCI remove device 00:1f.2
(XEN) PCI add device 01:00.0
(XEN) [VT-D]iommu.c:1431:d0 domain_context_unmap:PCIe: bdf = 1:0.0
(XEN) PCI remove device 01:00.0
(XEN) PCI add device 01:00.1
(XEN) [VT-D]iommu.c:1431:d0 domain_context_unmap:PCIe: bdf = 1:0.1
(XEN) PCI remove device 01:00.1
(XEN) PCI add device 02:00.0
(XEN) [VT-D]iommu.c:1431:d0 domain_context_unmap:PCIe: bdf = 2:0.0
(XEN) PCI remove device 02:00.0
(XEN) PCI add device 02:00.1
(XEN) [VT-D]iommu.c:1431:d0 domain_context_unmap:PCIe: bdf = 2:0.1
(XEN) PCI remove device 02:00.1
(XEN) PCI add device 03:00.0
(XEN) [VT-D]iommu.c:1431:d0 domain_context_unmap:PCIe: bdf = 3:0.0
(XEN) PCI remove device 03:00.0
(XEN) PCI add device 05:00.0
(XEN) PCI remove device 05:00.0
(XEN) PCI add device 06:02.0
(XEN) PCI remove device 06:02.0
(XEN) PCI add device 06:04.0
(XEN) PCI remove device 06:04.0
(XEN) PCI add device 07:00.0
(XEN) [VT-D]iommu.c:1431:d0 domain_context_unmap:PCIe: bdf = 7:0.0
(XEN) PCI remove device 07:00.0
(XEN) PCI add device 07:00.1
(XEN) [VT-D]iommu.c:1431:d0 domain_context_unmap:PCIe: bdf = 7:0.1
(XEN) PCI remove device 07:00.1
(XEN) PCI add device 08:00.0
(XEN) [VT-D]iommu.c:1431:d0 domain_context_unmap:PCIe: bdf = 8:0.0
(XEN) PCI remove device 08:00.0
(XEN) PCI add device 08:00.1
(XEN) [VT-D]iommu.c:1431:d0 domain_context_unmap:PCIe: bdf = 8:0.1
(XEN) PCI remove device 08:00.1
(XEN) PCI add device 0b:03.0
(XEN) [VT-D]iommu.c:1438:d0 domain_context_unmap:PCI: bdf = b:3.0
(XEN) PCI remove device 0b:03.0
[    2.754738] PCI: Bridge: 0000:00:01.0
[    2.760443]   IO window: disabled.
[    2.763671]   MEM window: 0xd6000000-0xd9ffffff
[    2.769615]   PREFETCH window: disabled.
[    2.773455] PCI: Bridge: 0000:00:03.0
[    2.777919]   IO window: disabled.
[    2.781226]   MEM window: 0xda000000-0xddffffff
[    2.789224]   PREFETCH window: disabled.
[    2.793052] PCI: Bridge: 0000:00:04.0
[    2.796617]   IO window: f000-ffff
[    2.800613]   MEM window: 0xdfd00000-0xdfefffff
[    2.804866]   PREFETCH window: disabled.
[    2.809596] PCI: Bridge: 0000:00:05.0
[    2.813355]   IO window: disabled.
[    2.817196]   MEM window: disabled.
[    2.820733]   PREFETCH window: disabled.
[    2.824564] PCI: Bridge: 0000:06:02.0
[    2.829130]   IO window: e000-efff
[    2.832660]   MEM window: 0xdf600000-0xdfbfffff
[    2.837140]   PREFETCH window: disabled.
[    2.841022] PCI: Bridge: 0000:06:04.0
[    2.844722]   IO window: d000-dfff
[    2.848937]   MEM window: 0xdf000000-0xdf5fffff
[    2.853523]   PREFETCH window: disabled.
[    2.857404] PCI: Bridge: 0000:05:00.0
[    2.861120]   IO window: d000-efff
[    2.864432]   MEM window: 0xdf000000-0xdfbfffff
[    2.869806]   PREFETCH window: disabled.
[    2.873683] PCI: Bridge: 0000:00:06.0
[    2.877375]   IO window: d000-efff
[    2.880694]   MEM window: 0xdf000000-0xdfbfffff
[    2.885949]   PREFETCH window: disabled.
[    2.890633] PCI: Bridge: 0000:00:07.0
[    2.894208]   IO window: disabled.
[    2.897664]   MEM window: disabled.
[    2.901479]   PREFETCH window: disabled.
[    2.905510] PCI: Bridge: 0000:00:09.0
[    2.909023]   IO window: disabled.
[    2.913309]   MEM window: disabled.
[    2.916786]   PREFETCH window: disabled.
[    2.920791] PCI: Bridge: 0000:00:1e.0
[    2.924383]   IO window: disabled.
[    2.928223]   MEM window: 0xde000000-0xdeffffff
[    2.933548]   PREFETCH window: 0x00000000d5800000-0x00000000d5ffffff
(XEN) allocated vector for irq:53
[    2.943312] ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 53 (level, low) -> IRQ 53
[    2.951694] ACPI: PCI Interrupt 0000:00:03.0[A] -> GSI 53 (level, low) -> IRQ 53
[    2.960567] ACPI: PCI Interrupt 0000:00:04.0[A] -> GSI 53 (level, low) -> IRQ 53
[    2.968660] ACPI: PCI Interrupt 0000:00:05.0[A] -> GSI 53 (level, low) -> IRQ 53
[    2.976707] ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 53 (level, low) -> IRQ 53
[    2.984964] ACPI: PCI Interrupt 0000:00:07.0[A] -> GSI 53 (level, low) -> IRQ 53
[    2.992235] ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 53 (level, low) -> IRQ 53
[    3.000959] NET: Registered protocol family 2
[    3.005475] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
[    3.017258] TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
[    3.025806] TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
[    3.032409] TCP: Hash tables configured (established 131072 bind 65536)
[    3.039050] TCP reno registered
[    3.043202] NET: Registered protocol family 1
[    3.047606] checking if image is initramfs... it is
[    3.076684] Freeing initrd memory: 16356k freed
[    3.094127] audit: initializing netlink socket (disabled)
[    3.104458] type=2000 audit(1267036398.127:1): initialized
[    3.113892] highmem bounce pool size: 64 pages
[    3.119879] VFS: Disk quotas dquot_6.5.1
[    3.123717] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    3.130345] msgmni has been set to 1751
[    3.136171] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    3.141068] io scheduler noop registered
[    3.144483] io scheduler anticipatory registered
[    3.152485] io scheduler deadline registered
[    3.156798] io scheduler cfq registered (default)
(XEN) PCI add device 00:01.0
[    3.178537] assign_interrupt_mode Found MSI capability
[    3.183598] no ownder
(XEN) ----[ Xen-4.0.0-rc4  x86_64  debug=n  Tainted:    C ]----
(XEN) CPU:    15
(XEN) RIP:    e008:[<ffff82c4801535a9>] pci_enable_msi+0x4c9/0x580
(XEN) RFLAGS: 0000000000010282   CONTEXT: hypervisor
(XEN) rax: ffff82c3ffeb6141   rbx: 0000000000000000   rcx: ffff830828b0e690
(XEN) rdx: ffff830828b0e718   rsi: ffff8300bf6975b0   rdi: ffff830828b0e6e0
(XEN) rbp: ffff83082cd7fec8   rsp: ffff83082cd7fd88   r8:  0000000000000005
(XEN) r9:  ffff830828b0e700   r10: 00000000000000a8   r11: 0000000000000040
(XEN) r12: ffff830828b0e710   r13: ffff830828b0e670   r14: ffff83082cd7fe38
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 000000043fdcf000   cr2: ffff82c3ffeb614d
(XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff83082cd7fd88:
(XEN)    0000000000000246 ffff830828b0e6e0 0000000080000000 0000000100000000
(XEN)    3408000000000000 0000000200000000 000f5861e4a00100 0000000000000141
(XEN)    ffff83082cd71ec8 ffff83082cd7fec8 0000000000000136 ffff83082cd60000
(XEN)    0000000000000038 00000000ffffffed 0000000000000000 ffff82c480154832
(XEN)    00000000000004d8 0000000000000038 00000000000000e0 ffff83083fd81c80
(XEN)    ffff830828b0e670 00000000f5861e0c 0000000000000000 ffff83082cd60000
(XEN)    ffff83082cd400f0 00000000f5861e0c 0000000000000136 0000000000000038
(XEN)    ffff83082cd7fec8 ffff82c4801ede5f 7265646e776f206f ffff82c48024c080
(XEN)    ffff83082cd60180 ffff83082cd7fe98 0000000000007ff0 ffffffffffffffff
(XEN)    0000000800000000 0000000100000000 ffff8308f5861e4a ffff82c4802eaa80
(XEN)    0000000800000000 0000000000000038 f5861e4a00000001 000000000000000f
(XEN)    ffffffffffffffff ffff8300bf2e8000 0000000000000035 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 ffff82c4801ef863
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000035 000000000000000d 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000021 00000000f5861e0c
(XEN)    00000000c033741f 00000000ffffffff 0000000000000000 0000010000000000
(XEN)    00000000c0101427 0000000000000061 0000000000000286 00000000f5861e08
(XEN)    0000000000000069 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 000000000000000f ffff8300bf2e8000
(XEN) Xen call trace:
(XEN)    [<ffff82c4801535a9>] pci_enable_msi+0x4c9/0x580
(XEN)    [<ffff82c480154832>] map_domain_pirq+0x242/0x2f0
(XEN)    [<ffff82c4801ede5f>] compat_physdev_op+0xc8f/0x1010
(XEN)    [<ffff82c4801ef863>] compat_hypercall+0x83/0x90
(XEN)    
(XEN) Pagetable walk from ffff82c3ffeb614d:
(XEN)  L4[0x105] = 00000000bf4e2027 5555555555555555
(XEN)  L3[0x10f] = 00000000bf698063 5555555555555555
(XEN)  L2[0x1ff] = 00000000bf697063 5555555555555555 
(XEN)  L1[0x0b6] = f5861e4a00100173 ffffffffffffffff
(XEN) 
(XEN) ****************************************
(XEN) Panic on CPU 15:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=000b]
(XEN) Faulting linear address: ffff82c3ffeb614d
(XEN) ****************************************
(XEN) 
(XEN) Reboot in five seconds...

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-24 18:47 Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686) George Dunlap
@ 2010-02-24 19:08 ` Sander Eikelenboom
  2010-02-24 20:20   ` Pasi Kärkkäinen
  0 siblings, 1 reply; 26+ messages in thread
From: Sander Eikelenboom @ 2010-02-24 19:08 UTC (permalink / raw)
  To: George Dunlap; +Cc: xen-devel


Wasn't pci=nomsi required for those kernels ?


Wednesday, February 24, 2010, 7:47:09 PM, you wrote:

> I recenty tried to boot my Debian lenny distro on a newer Intel
> Nehalem box using Debian Lenny's default xen kernel
> (2.6.26-2-xen-686), and it crashed during boot.  Full log attached,
> but the key info is here:

> I tried doing a "binary search" to see where this was introduced, but
> it fails the same way all the way back to c/s 20000.

> The same kernel/hypervisor combination boots fine on a different box I have.

>  -George

> (XEN) ----[ Xen-4.0.0-rc4  x86_64  debug=n  Tainted:    C ]----
> (XEN) CPU:    15
> (XEN) RIP:    e008:[<ffff82c4801535a9>] pci_enable_msi+0x4c9/0x580
> (XEN) RFLAGS: 0000000000010282   CONTEXT: hypervisor
> (XEN) rax: ffff82c3ffeb6141   rbx: 0000000000000000   rcx: ffff830828b0e690
> (XEN) rdx: ffff830828b0e718   rsi: ffff8300bf6975b0   rdi: ffff830828b0e6e0
> (XEN) rbp: ffff83082cd7fec8   rsp: ffff83082cd7fd88   r8:  0000000000000005
> (XEN) r9:  ffff830828b0e700   r10: 00000000000000a8   r11: 0000000000000040
> (XEN) r12: ffff830828b0e710   r13: ffff830828b0e670   r14: ffff83082cd7fe38
> (XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000026f0
> (XEN) cr3: 000000043fdcf000   cr2: ffff82c3ffeb614d
> (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0000   cs: e008
> (XEN) Xen stack trace from rsp=ffff83082cd7fd88:
> (XEN)    0000000000000246 ffff830828b0e6e0 0000000080000000 0000000100000000
> (XEN)    3408000000000000 0000000200000000 000f5861e4a00100 0000000000000141
> (XEN)    ffff83082cd71ec8 ffff83082cd7fec8 0000000000000136 ffff83082cd60000
> (XEN)    0000000000000038 00000000ffffffed 0000000000000000 ffff82c480154832
> (XEN)    00000000000004d8 0000000000000038 00000000000000e0 ffff83083fd81c80
> (XEN)    ffff830828b0e670 00000000f5861e0c 0000000000000000 ffff83082cd60000
> (XEN)    ffff83082cd400f0 00000000f5861e0c 0000000000000136 0000000000000038
> (XEN)    ffff83082cd7fec8 ffff82c4801ede5f 7265646e776f206f ffff82c48024c080
> (XEN)    ffff83082cd60180 ffff83082cd7fe98 0000000000007ff0 ffffffffffffffff
> (XEN)    0000000800000000 0000000100000000 ffff8308f5861e4a ffff82c4802eaa80
> (XEN)    0000000800000000 0000000000000038 f5861e4a00000001 000000000000000f
> (XEN)    ffffffffffffffff ffff8300bf2e8000 0000000000000035 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 ffff82c4801ef863
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000035 000000000000000d 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000021 00000000f5861e0c
> (XEN)    00000000c033741f 00000000ffffffff 0000000000000000 0000010000000000
> (XEN)    00000000c0101427 0000000000000061 0000000000000286 00000000f5861e08
> (XEN)    0000000000000069 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 000000000000000f ffff8300bf2e8000
> (XEN) Xen call trace:
> (XEN)    [<ffff82c4801535a9>] pci_enable_msi+0x4c9/0x580
> (XEN)    [<ffff82c480154832>] map_domain_pirq+0x242/0x2f0
> (XEN)    [<ffff82c4801ede5f>] compat_physdev_op+0xc8f/0x1010
> (XEN)    [<ffff82c4801ef863>] compat_hypercall+0x83/0x90
> (XEN)
> (XEN) Pagetable walk from ffff82c3ffeb614d:
> (XEN)  L4[0x105] = 00000000bf4e2027 5555555555555555
> (XEN)  L3[0x10f] = 00000000bf698063 5555555555555555
> (XEN)  L2[0x1ff] = 00000000bf697063 5555555555555555
> (XEN)  L1[0x0b6] = f5861e4a00100173 ffffffffffffffff
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 15:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=000b]
> (XEN) Faulting linear address: ffff82c3ffeb614d
> (XEN) ****************************************



-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-24 19:08 ` Sander Eikelenboom
@ 2010-02-24 20:20   ` Pasi Kärkkäinen
  2010-02-24 23:57     ` George Dunlap
  0 siblings, 1 reply; 26+ messages in thread
From: Pasi Kärkkäinen @ 2010-02-24 20:20 UTC (permalink / raw)
  To: Sander Eikelenboom; +Cc: George Dunlap, xen-devel

On Wed, Feb 24, 2010 at 08:08:10PM +0100, Sander Eikelenboom wrote:
> 
> Wasn't pci=nomsi required for those kernels ?
> 

Yeah, pci=nomsi has been the workaround for this bug..
Many people have seen (and reported) this bug in the lenny kernel.

Would be good to hunt down the actual reason..

-- Pasi

> 
> Wednesday, February 24, 2010, 7:47:09 PM, you wrote:
> 
> > I recenty tried to boot my Debian lenny distro on a newer Intel
> > Nehalem box using Debian Lenny's default xen kernel
> > (2.6.26-2-xen-686), and it crashed during boot.  Full log attached,
> > but the key info is here:
> 
> > I tried doing a "binary search" to see where this was introduced, but
> > it fails the same way all the way back to c/s 20000.
> 
> > The same kernel/hypervisor combination boots fine on a different box I have.
> 
> >  -George
> 
> > (XEN) ----[ Xen-4.0.0-rc4  x86_64  debug=n  Tainted:    C ]----
> > (XEN) CPU:    15
> > (XEN) RIP:    e008:[<ffff82c4801535a9>] pci_enable_msi+0x4c9/0x580
> > (XEN) RFLAGS: 0000000000010282   CONTEXT: hypervisor
> > (XEN) rax: ffff82c3ffeb6141   rbx: 0000000000000000   rcx: ffff830828b0e690
> > (XEN) rdx: ffff830828b0e718   rsi: ffff8300bf6975b0   rdi: ffff830828b0e6e0
> > (XEN) rbp: ffff83082cd7fec8   rsp: ffff83082cd7fd88   r8:  0000000000000005
> > (XEN) r9:  ffff830828b0e700   r10: 00000000000000a8   r11: 0000000000000040
> > (XEN) r12: ffff830828b0e710   r13: ffff830828b0e670   r14: ffff83082cd7fe38
> > (XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000026f0
> > (XEN) cr3: 000000043fdcf000   cr2: ffff82c3ffeb614d
> > (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0000   cs: e008
> > (XEN) Xen stack trace from rsp=ffff83082cd7fd88:
> > (XEN)    0000000000000246 ffff830828b0e6e0 0000000080000000 0000000100000000
> > (XEN)    3408000000000000 0000000200000000 000f5861e4a00100 0000000000000141
> > (XEN)    ffff83082cd71ec8 ffff83082cd7fec8 0000000000000136 ffff83082cd60000
> > (XEN)    0000000000000038 00000000ffffffed 0000000000000000 ffff82c480154832
> > (XEN)    00000000000004d8 0000000000000038 00000000000000e0 ffff83083fd81c80
> > (XEN)    ffff830828b0e670 00000000f5861e0c 0000000000000000 ffff83082cd60000
> > (XEN)    ffff83082cd400f0 00000000f5861e0c 0000000000000136 0000000000000038
> > (XEN)    ffff83082cd7fec8 ffff82c4801ede5f 7265646e776f206f ffff82c48024c080
> > (XEN)    ffff83082cd60180 ffff83082cd7fe98 0000000000007ff0 ffffffffffffffff
> > (XEN)    0000000800000000 0000000100000000 ffff8308f5861e4a ffff82c4802eaa80
> > (XEN)    0000000800000000 0000000000000038 f5861e4a00000001 000000000000000f
> > (XEN)    ffffffffffffffff ffff8300bf2e8000 0000000000000035 0000000000000000
> > (XEN)    0000000000000000 0000000000000000 0000000000000000 ffff82c4801ef863
> > (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN)    0000000000000035 000000000000000d 0000000000000000 0000000000000000
> > (XEN)    0000000000000000 0000000000000000 0000000000000021 00000000f5861e0c
> > (XEN)    00000000c033741f 00000000ffffffff 0000000000000000 0000010000000000
> > (XEN)    00000000c0101427 0000000000000061 0000000000000286 00000000f5861e08
> > (XEN)    0000000000000069 0000000000000000 0000000000000000 0000000000000000
> > (XEN)    0000000000000000 000000000000000f ffff8300bf2e8000
> > (XEN) Xen call trace:
> > (XEN)    [<ffff82c4801535a9>] pci_enable_msi+0x4c9/0x580
> > (XEN)    [<ffff82c480154832>] map_domain_pirq+0x242/0x2f0
> > (XEN)    [<ffff82c4801ede5f>] compat_physdev_op+0xc8f/0x1010
> > (XEN)    [<ffff82c4801ef863>] compat_hypercall+0x83/0x90
> > (XEN)
> > (XEN) Pagetable walk from ffff82c3ffeb614d:
> > (XEN)  L4[0x105] = 00000000bf4e2027 5555555555555555
> > (XEN)  L3[0x10f] = 00000000bf698063 5555555555555555
> > (XEN)  L2[0x1ff] = 00000000bf697063 5555555555555555
> > (XEN)  L1[0x0b6] = f5861e4a00100173 ffffffffffffffff
> > (XEN)
> > (XEN) ****************************************
> > (XEN) Panic on CPU 15:
> > (XEN) FATAL PAGE FAULT
> > (XEN) [error_code=000b]
> > (XEN) Faulting linear address: ffff82c3ffeb614d
> > (XEN) ****************************************
> 
> 
> 
> -- 
> Best regards,
>  Sander                            mailto:linux@eikelenboom.it
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-24 20:20   ` Pasi Kärkkäinen
@ 2010-02-24 23:57     ` George Dunlap
  2010-02-25  6:50       ` Jiang, Yunhong
  2010-02-25  9:16       ` Jan Beulich
  0 siblings, 2 replies; 26+ messages in thread
From: George Dunlap @ 2010-02-24 23:57 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Sander Eikelenboom, xen-devel

pci=nomsi in the guest command line?

I realize dom0 is a privileged guest, but it still seems like we
should try not to crash Xen as a result on guest input. :-)

Thanks for the work-around,
 -George

On Wed, Feb 24, 2010 at 8:20 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Wed, Feb 24, 2010 at 08:08:10PM +0100, Sander Eikelenboom wrote:
>>
>> Wasn't pci=nomsi required for those kernels ?
>>
>
> Yeah, pci=nomsi has been the workaround for this bug..
> Many people have seen (and reported) this bug in the lenny kernel.
>
> Would be good to hunt down the actual reason..
>
> -- Pasi
>
>>
>> Wednesday, February 24, 2010, 7:47:09 PM, you wrote:
>>
>> > I recenty tried to boot my Debian lenny distro on a newer Intel
>> > Nehalem box using Debian Lenny's default xen kernel
>> > (2.6.26-2-xen-686), and it crashed during boot.  Full log attached,
>> > but the key info is here:
>>
>> > I tried doing a "binary search" to see where this was introduced, but
>> > it fails the same way all the way back to c/s 20000.
>>
>> > The same kernel/hypervisor combination boots fine on a different box I have.
>>
>> >  -George
>>
>> > (XEN) ----[ Xen-4.0.0-rc4  x86_64  debug=n  Tainted:    C ]----
>> > (XEN) CPU:    15
>> > (XEN) RIP:    e008:[<ffff82c4801535a9>] pci_enable_msi+0x4c9/0x580
>> > (XEN) RFLAGS: 0000000000010282   CONTEXT: hypervisor
>> > (XEN) rax: ffff82c3ffeb6141   rbx: 0000000000000000   rcx: ffff830828b0e690
>> > (XEN) rdx: ffff830828b0e718   rsi: ffff8300bf6975b0   rdi: ffff830828b0e6e0
>> > (XEN) rbp: ffff83082cd7fec8   rsp: ffff83082cd7fd88   r8:  0000000000000005
>> > (XEN) r9:  ffff830828b0e700   r10: 00000000000000a8   r11: 0000000000000040
>> > (XEN) r12: ffff830828b0e710   r13: ffff830828b0e670   r14: ffff83082cd7fe38
>> > (XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000026f0
>> > (XEN) cr3: 000000043fdcf000   cr2: ffff82c3ffeb614d
>> > (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0000   cs: e008
>> > (XEN) Xen stack trace from rsp=ffff83082cd7fd88:
>> > (XEN)    0000000000000246 ffff830828b0e6e0 0000000080000000 0000000100000000
>> > (XEN)    3408000000000000 0000000200000000 000f5861e4a00100 0000000000000141
>> > (XEN)    ffff83082cd71ec8 ffff83082cd7fec8 0000000000000136 ffff83082cd60000
>> > (XEN)    0000000000000038 00000000ffffffed 0000000000000000 ffff82c480154832
>> > (XEN)    00000000000004d8 0000000000000038 00000000000000e0 ffff83083fd81c80
>> > (XEN)    ffff830828b0e670 00000000f5861e0c 0000000000000000 ffff83082cd60000
>> > (XEN)    ffff83082cd400f0 00000000f5861e0c 0000000000000136 0000000000000038
>> > (XEN)    ffff83082cd7fec8 ffff82c4801ede5f 7265646e776f206f ffff82c48024c080
>> > (XEN)    ffff83082cd60180 ffff83082cd7fe98 0000000000007ff0 ffffffffffffffff
>> > (XEN)    0000000800000000 0000000100000000 ffff8308f5861e4a ffff82c4802eaa80
>> > (XEN)    0000000800000000 0000000000000038 f5861e4a00000001 000000000000000f
>> > (XEN)    ffffffffffffffff ffff8300bf2e8000 0000000000000035 0000000000000000
>> > (XEN)    0000000000000000 0000000000000000 0000000000000000 ffff82c4801ef863
>> > (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> > (XEN)    0000000000000035 000000000000000d 0000000000000000 0000000000000000
>> > (XEN)    0000000000000000 0000000000000000 0000000000000021 00000000f5861e0c
>> > (XEN)    00000000c033741f 00000000ffffffff 0000000000000000 0000010000000000
>> > (XEN)    00000000c0101427 0000000000000061 0000000000000286 00000000f5861e08
>> > (XEN)    0000000000000069 0000000000000000 0000000000000000 0000000000000000
>> > (XEN)    0000000000000000 000000000000000f ffff8300bf2e8000
>> > (XEN) Xen call trace:
>> > (XEN)    [<ffff82c4801535a9>] pci_enable_msi+0x4c9/0x580
>> > (XEN)    [<ffff82c480154832>] map_domain_pirq+0x242/0x2f0
>> > (XEN)    [<ffff82c4801ede5f>] compat_physdev_op+0xc8f/0x1010
>> > (XEN)    [<ffff82c4801ef863>] compat_hypercall+0x83/0x90
>> > (XEN)
>> > (XEN) Pagetable walk from ffff82c3ffeb614d:
>> > (XEN)  L4[0x105] = 00000000bf4e2027 5555555555555555
>> > (XEN)  L3[0x10f] = 00000000bf698063 5555555555555555
>> > (XEN)  L2[0x1ff] = 00000000bf697063 5555555555555555
>> > (XEN)  L1[0x0b6] = f5861e4a00100173 ffffffffffffffff
>> > (XEN)
>> > (XEN) ****************************************
>> > (XEN) Panic on CPU 15:
>> > (XEN) FATAL PAGE FAULT
>> > (XEN) [error_code=000b]
>> > (XEN) Faulting linear address: ffff82c3ffeb614d
>> > (XEN) ****************************************
>>
>>
>>
>> --
>> Best regards,
>>  Sander                            mailto:linux@eikelenboom.it
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-24 23:57     ` George Dunlap
@ 2010-02-25  6:50       ` Jiang, Yunhong
  2010-02-25 10:48         ` George Dunlap
  2010-02-25  9:16       ` Jan Beulich
  1 sibling, 1 reply; 26+ messages in thread
From: Jiang, Yunhong @ 2010-02-25  6:50 UTC (permalink / raw)
  To: George Dunlap, Pasi Kärkkäinen; +Cc: Sander Eikelenboom, xen-devel

Agree that Xen should not crash on such situation.

Since it is enabling MSI, I try to check the code in __pci_enable_msi(), and didn't find any suspicious code. As 0x ffff82c3ffeb614d is at ioremap range, I suspect it is about msix fixmap, but still didn't find any hint.
The page table walk is a bit strange to me. The L1 entry is suspicious, seems it clobered.
Can you share the code around the fault IP address?

--jyh


(XEN) Pagetable walk from ffff82c3ffeb614d:
(XEN)  L4[0x105] = 00000000bf4e2027 5555555555555555
(XEN)  L3[0x10f] = 00000000bf698063 5555555555555555
(XEN)  L2[0x1ff] = 00000000bf697063 5555555555555555
(XEN)  L1[0x0b6] = f5861e4a00100173 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 15:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=000b]
(XEN) Faulting linear address: ffff82c3ffeb614d
(XEN) ****************************************



>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of George Dunlap
>Sent: Thursday, February 25, 2010 7:58 AM
>To: Pasi Kärkkäinen
>Cc: Sander Eikelenboom; xen-devel@lists.xensource.com
>Subject: Re: [Xen-devel] Crash during boot in Debian lenny default dom0 kernel
>(2.6.26-2-xen-686)
>
>pci=nomsi in the guest command line?
>
>I realize dom0 is a privileged guest, but it still seems like we
>should try not to crash Xen as a result on guest input. :-)
>
>Thanks for the work-around,
> -George
>
>On Wed, Feb 24, 2010 at 8:20 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
>> On Wed, Feb 24, 2010 at 08:08:10PM +0100, Sander Eikelenboom wrote:
>>>
>>> Wasn't pci=nomsi required for those kernels ?
>>>
>>
>> Yeah, pci=nomsi has been the workaround for this bug..
>> Many people have seen (and reported) this bug in the lenny kernel.
>>
>> Would be good to hunt down the actual reason..
>>
>> -- Pasi
>>
>>>
>>> Wednesday, February 24, 2010, 7:47:09 PM, you wrote:
>>>
>>> > I recenty tried to boot my Debian lenny distro on a newer Intel
>>> > Nehalem box using Debian Lenny's default xen kernel
>>> > (2.6.26-2-xen-686), and it crashed during boot.  Full log attached,
>>> > but the key info is here:
>>>
>>> > I tried doing a "binary search" to see where this was introduced, but
>>> > it fails the same way all the way back to c/s 20000.
>>>
>>> > The same kernel/hypervisor combination boots fine on a different box I have.
>>>
>>> >  -George
>>>
>>> > (XEN) ----[ Xen-4.0.0-rc4  x86_64  debug=n  Tainted:    C ]----
>>> > (XEN) CPU:    15
>>> > (XEN) RIP:    e008:[<ffff82c4801535a9>] pci_enable_msi+0x4c9/0x580
>>> > (XEN) RFLAGS: 0000000000010282   CONTEXT: hypervisor
>>> > (XEN) rax: ffff82c3ffeb6141   rbx: 0000000000000000   rcx:
>ffff830828b0e690
>>> > (XEN) rdx: ffff830828b0e718   rsi: ffff8300bf6975b0   rdi: ffff830828b0e6e0
>>> > (XEN) rbp: ffff83082cd7fec8   rsp:
>ffff83082cd7fd88   r8:  0000000000000005
>>> > (XEN) r9:  ffff830828b0e700   r10: 00000000000000a8   r11:
>0000000000000040
>>> > (XEN) r12: ffff830828b0e710   r13: ffff830828b0e670   r14: ffff83082cd7fe38
>>> > (XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4:
>00000000000026f0
>>> > (XEN) cr3: 000000043fdcf000   cr2: ffff82c3ffeb614d
>>> > (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0000   cs: e008
>>> > (XEN) Xen stack trace from rsp=ffff83082cd7fd88:
>>> > (XEN)    0000000000000246 ffff830828b0e6e0 0000000080000000
>0000000100000000
>>> > (XEN)    3408000000000000 0000000200000000 000f5861e4a00100
>0000000000000141
>>> > (XEN)    ffff83082cd71ec8 ffff83082cd7fec8 0000000000000136
>ffff83082cd60000
>>> > (XEN)    0000000000000038 00000000ffffffed 0000000000000000
>ffff82c480154832
>>> > (XEN)    00000000000004d8 0000000000000038 00000000000000e0
>ffff83083fd81c80
>>> > (XEN)    ffff830828b0e670 00000000f5861e0c 0000000000000000
>ffff83082cd60000
>>> > (XEN)    ffff83082cd400f0 00000000f5861e0c 0000000000000136
>0000000000000038
>>> > (XEN)    ffff83082cd7fec8 ffff82c4801ede5f 7265646e776f206f
>ffff82c48024c080
>>> > (XEN)    ffff83082cd60180 ffff83082cd7fe98 0000000000007ff0 ffffffffffffffff
>>> > (XEN)    0000000800000000 0000000100000000 ffff8308f5861e4a
>ffff82c4802eaa80
>>> > (XEN)    0000000800000000 0000000000000038 f5861e4a00000001
>000000000000000f
>>> > (XEN)    ffffffffffffffff ffff8300bf2e8000 0000000000000035
>0000000000000000
>>> > (XEN)    0000000000000000 0000000000000000 0000000000000000
>ffff82c4801ef863
>>> > (XEN)    0000000000000000 0000000000000000 0000000000000000
>0000000000000000
>>> > (XEN)    0000000000000035 000000000000000d 0000000000000000
>0000000000000000
>>> > (XEN)    0000000000000000 0000000000000000 0000000000000021
>00000000f5861e0c
>>> > (XEN)    00000000c033741f 00000000ffffffff 0000000000000000
>0000010000000000
>>> > (XEN)    00000000c0101427 0000000000000061 0000000000000286
>00000000f5861e08
>>> > (XEN)    0000000000000069 0000000000000000 0000000000000000
>0000000000000000
>>> > (XEN)    0000000000000000 000000000000000f ffff8300bf2e8000
>>> > (XEN) Xen call trace:
>>> > (XEN)    [<ffff82c4801535a9>] pci_enable_msi+0x4c9/0x580
>>> > (XEN)    [<ffff82c480154832>] map_domain_pirq+0x242/0x2f0
>>> > (XEN)    [<ffff82c4801ede5f>] compat_physdev_op+0xc8f/0x1010
>>> > (XEN)    [<ffff82c4801ef863>] compat_hypercall+0x83/0x90
>>> > (XEN)
>>> > (XEN) Pagetable walk from ffff82c3ffeb614d:
>>> > (XEN)  L4[0x105] = 00000000bf4e2027 5555555555555555
>>> > (XEN)  L3[0x10f] = 00000000bf698063 5555555555555555
>>> > (XEN)  L2[0x1ff] = 00000000bf697063 5555555555555555
>>> > (XEN)  L1[0x0b6] = f5861e4a00100173 ffffffffffffffff
>>> > (XEN)
>>> > (XEN) ****************************************
>>> > (XEN) Panic on CPU 15:
>>> > (XEN) FATAL PAGE FAULT
>>> > (XEN) [error_code=000b]
>>> > (XEN) Faulting linear address: ffff82c3ffeb614d
>>> > (XEN) ****************************************
>>>
>>>
>>>
>>> --
>>> Best regards,
>>>  Sander                            mailto:linux@eikelenboom.it
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-24 23:57     ` George Dunlap
  2010-02-25  6:50       ` Jiang, Yunhong
@ 2010-02-25  9:16       ` Jan Beulich
  2010-02-25  9:28         ` Jiang, Yunhong
  1 sibling, 1 reply; 26+ messages in thread
From: Jan Beulich @ 2010-02-25  9:16 UTC (permalink / raw)
  To: George Dunlap, pasik; +Cc: Sander Eikelenboom, xen-devel

>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 00:57 >>>
>I realize dom0 is a privileged guest, but it still seems like we
>should try not to crash Xen as a result on guest input. :-)

While generally I agree, I think in the given case this is unavoidable -
Xen could apply some sanity check, but the passing of a machine
address from Dom0 to Xen implies that Dom0 knows what it does,
and Xen trusts it. Specifically, struct physdev_map_pirq has this
contents according to the trace

.domid = 00007ff0
.type = 00000000
.index = ffffffff
.pirq = ffffffff
.bus = 00000000
.devfn = 00000008
.entry_nr = 00000000
.table_base = f5861e4a00000001

table_base would seem like not having been initialized at all. I
would guess that they use the structure definition from before
c/s 18323 (which had, instead of a table_base member, an
int field indicating MSI vs. MSI-X. The original definition was
added with c/s 17534 and 17535, but all of those changes
happened during 3.3 development, so no-one should be using
the old definition in released code..

Jan

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-25  9:16       ` Jan Beulich
@ 2010-02-25  9:28         ` Jiang, Yunhong
  0 siblings, 0 replies; 26+ messages in thread
From: Jiang, Yunhong @ 2010-02-25  9:28 UTC (permalink / raw)
  To: Jan Beulich, George Dunlap, pasik; +Cc: Sander Eikelenboom, xen-devel

Seems the table_base is not initialized, otherwise, it should be 0x1, instead of 0x f5861e4a00000001.

I checked the libxc, and seems the parameter need be cleared in libxc. I didn't check kernel code now.
I suspect followed patch is needed (the patch is only compiled and not tested).

--jyh

diff -r 89dfe955f1c3 tools/libxc/xc_physdev.c
--- a/tools/libxc/xc_physdev.c  Thu Feb 25 17:17:02 2010 +0800
+++ b/tools/libxc/xc_physdev.c  Thu Feb 25 17:27:10 2010 +0800
@@ -31,6 +31,7 @@ int xc_physdev_map_pirq(int xc_handle,
     if ( !pirq )
         return -EINVAL;

+    memset(&map, 0, sizeof(struct physdev_map_pirq));
     map.domid = domid;
     map.type = MAP_PIRQ_TYPE_GSI;
     map.index = index;
@@ -59,6 +60,7 @@ int xc_physdev_map_pirq_msi(int xc_handl
     if ( !pirq )
         return -EINVAL;

+    memset(&map, 0, sizeof(struct physdev_map_pirq));
     map.domid = domid;
     map.type = MAP_PIRQ_TYPE_MSI;
     map.index = index;
@@ -83,6 +85,7 @@ int xc_physdev_unmap_pirq(int xc_handle,
     int rc;
     struct physdev_unmap_pirq unmap;

+    memset(&unmap, 0, sizeof(struct physdev_unmap_pirq));
     unmap.domid = domid;
     unmap.pirq = pirq;


>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Jan Beulich
>Sent: Thursday, February 25, 2010 5:16 PM
>To: George Dunlap; pasik@iki.fi
>Cc: Sander Eikelenboom; xen-devel@lists.xensource.com
>Subject: Re: [Xen-devel] Crash during boot in Debian lenny default dom0 kernel
>(2.6.26-2-xen-686)
>
>>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 00:57 >>>
>>I realize dom0 is a privileged guest, but it still seems like we
>>should try not to crash Xen as a result on guest input. :-)
>
>While generally I agree, I think in the given case this is unavoidable -
>Xen could apply some sanity check, but the passing of a machine
>address from Dom0 to Xen implies that Dom0 knows what it does,
>and Xen trusts it. Specifically, struct physdev_map_pirq has this
>contents according to the trace
>
>.domid = 00007ff0
>.type = 00000000
>.index = ffffffff
>.pirq = ffffffff
>.bus = 00000000
>.devfn = 00000008
>.entry_nr = 00000000
>.table_base = f5861e4a00000001
>
>table_base would seem like not having been initialized at all. I
>would guess that they use the structure definition from before
>c/s 18323 (which had, instead of a table_base member, an
>int field indicating MSI vs. MSI-X. The original definition was
>added with c/s 17534 and 17535, but all of those changes
>happened during 3.3 development, so no-one should be using
>the old definition in released code..
>
>Jan
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-25  6:50       ` Jiang, Yunhong
@ 2010-02-25 10:48         ` George Dunlap
  2010-02-25 10:56           ` Jan Beulich
  0 siblings, 1 reply; 26+ messages in thread
From: George Dunlap @ 2010-02-25 10:48 UTC (permalink / raw)
  To: Jiang, Yunhong; +Cc: Sander Eikelenboom, xen-devel

$ addr2line -e xen/xen-syms 0xffff82c4801535a9
/xensource/hg/open-source/xen-unstable.hg/xen/arch/x86/msi.c:588

Which in my code is:
    /* Mask interrupt here */
    writel(1, entry->mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);

And tracing back, ->mask_base is computed in part with table_base
(which as Jan pointed out, seems borked).

Hmm... Jan said according to the stack:
.table_base = f5861e4a00000001

Is it possible that there's actually a bug in the compat code, and
that table_base actually *was* set to (uint32_t)1?  If a reasonable
number for table_base is "1", giving it 64 bits in the structure would
seem a bit like overkill...

 -George

On Thu, Feb 25, 2010 at 6:50 AM, Jiang, Yunhong <yunhong.jiang@intel.com> wrote:
> Agree that Xen should not crash on such situation.
>
> Since it is enabling MSI, I try to check the code in __pci_enable_msi(), and didn't find any suspicious code. As 0x ffff82c3ffeb614d is at ioremap range, I suspect it is about msix fixmap, but still didn't find any hint.
> The page table walk is a bit strange to me. The L1 entry is suspicious, seems it clobered.
> Can you share the code around the fault IP address?
>
> --jyh
>
>
> (XEN) Pagetable walk from ffff82c3ffeb614d:
> (XEN)  L4[0x105] = 00000000bf4e2027 5555555555555555
> (XEN)  L3[0x10f] = 00000000bf698063 5555555555555555
> (XEN)  L2[0x1ff] = 00000000bf697063 5555555555555555
> (XEN)  L1[0x0b6] = f5861e4a00100173 ffffffffffffffff
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 15:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=000b]
> (XEN) Faulting linear address: ffff82c3ffeb614d
> (XEN) ****************************************
>
>
>
>>-----Original Message-----
>>From: xen-devel-bounces@lists.xensource.com
>>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of George Dunlap
>>Sent: Thursday, February 25, 2010 7:58 AM
>>To: Pasi Kärkkäinen
>>Cc: Sander Eikelenboom; xen-devel@lists.xensource.com
>>Subject: Re: [Xen-devel] Crash during boot in Debian lenny default dom0 kernel
>>(2.6.26-2-xen-686)
>>
>>pci=nomsi in the guest command line?
>>
>>I realize dom0 is a privileged guest, but it still seems like we
>>should try not to crash Xen as a result on guest input. :-)
>>
>>Thanks for the work-around,
>> -George
>>
>>On Wed, Feb 24, 2010 at 8:20 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
>>> On Wed, Feb 24, 2010 at 08:08:10PM +0100, Sander Eikelenboom wrote:
>>>>
>>>> Wasn't pci=nomsi required for those kernels ?
>>>>
>>>
>>> Yeah, pci=nomsi has been the workaround for this bug..
>>> Many people have seen (and reported) this bug in the lenny kernel.
>>>
>>> Would be good to hunt down the actual reason..
>>>
>>> -- Pasi
>>>
>>>>
>>>> Wednesday, February 24, 2010, 7:47:09 PM, you wrote:
>>>>
>>>> > I recenty tried to boot my Debian lenny distro on a newer Intel
>>>> > Nehalem box using Debian Lenny's default xen kernel
>>>> > (2.6.26-2-xen-686), and it crashed during boot.  Full log attached,
>>>> > but the key info is here:
>>>>
>>>> > I tried doing a "binary search" to see where this was introduced, but
>>>> > it fails the same way all the way back to c/s 20000.
>>>>
>>>> > The same kernel/hypervisor combination boots fine on a different box I have.
>>>>
>>>> >  -George
>>>>
>>>> > (XEN) ----[ Xen-4.0.0-rc4  x86_64  debug=n  Tainted:    C ]----
>>>> > (XEN) CPU:    15
>>>> > (XEN) RIP:    e008:[<ffff82c4801535a9>] pci_enable_msi+0x4c9/0x580
>>>> > (XEN) RFLAGS: 0000000000010282   CONTEXT: hypervisor
>>>> > (XEN) rax: ffff82c3ffeb6141   rbx: 0000000000000000   rcx:
>>ffff830828b0e690
>>>> > (XEN) rdx: ffff830828b0e718   rsi: ffff8300bf6975b0   rdi: ffff830828b0e6e0
>>>> > (XEN) rbp: ffff83082cd7fec8   rsp:
>>ffff83082cd7fd88   r8:  0000000000000005
>>>> > (XEN) r9:  ffff830828b0e700   r10: 00000000000000a8   r11:
>>0000000000000040
>>>> > (XEN) r12: ffff830828b0e710   r13: ffff830828b0e670   r14: ffff83082cd7fe38
>>>> > (XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4:
>>00000000000026f0
>>>> > (XEN) cr3: 000000043fdcf000   cr2: ffff82c3ffeb614d
>>>> > (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0000   cs: e008
>>>> > (XEN) Xen stack trace from rsp=ffff83082cd7fd88:
>>>> > (XEN)    0000000000000246 ffff830828b0e6e0 0000000080000000
>>0000000100000000
>>>> > (XEN)    3408000000000000 0000000200000000 000f5861e4a00100
>>0000000000000141
>>>> > (XEN)    ffff83082cd71ec8 ffff83082cd7fec8 0000000000000136
>>ffff83082cd60000
>>>> > (XEN)    0000000000000038 00000000ffffffed 0000000000000000
>>ffff82c480154832
>>>> > (XEN)    00000000000004d8 0000000000000038 00000000000000e0
>>ffff83083fd81c80
>>>> > (XEN)    ffff830828b0e670 00000000f5861e0c 0000000000000000
>>ffff83082cd60000
>>>> > (XEN)    ffff83082cd400f0 00000000f5861e0c 0000000000000136
>>0000000000000038
>>>> > (XEN)    ffff83082cd7fec8 ffff82c4801ede5f 7265646e776f206f
>>ffff82c48024c080
>>>> > (XEN)    ffff83082cd60180 ffff83082cd7fe98 0000000000007ff0 ffffffffffffffff
>>>> > (XEN)    0000000800000000 0000000100000000 ffff8308f5861e4a
>>ffff82c4802eaa80
>>>> > (XEN)    0000000800000000 0000000000000038 f5861e4a00000001
>>000000000000000f
>>>> > (XEN)    ffffffffffffffff ffff8300bf2e8000 0000000000000035
>>0000000000000000
>>>> > (XEN)    0000000000000000 0000000000000000 0000000000000000
>>ffff82c4801ef863
>>>> > (XEN)    0000000000000000 0000000000000000 0000000000000000
>>0000000000000000
>>>> > (XEN)    0000000000000035 000000000000000d 0000000000000000
>>0000000000000000
>>>> > (XEN)    0000000000000000 0000000000000000 0000000000000021
>>00000000f5861e0c
>>>> > (XEN)    00000000c033741f 00000000ffffffff 0000000000000000
>>0000010000000000
>>>> > (XEN)    00000000c0101427 0000000000000061 0000000000000286
>>00000000f5861e08
>>>> > (XEN)    0000000000000069 0000000000000000 0000000000000000
>>0000000000000000
>>>> > (XEN)    0000000000000000 000000000000000f ffff8300bf2e8000
>>>> > (XEN) Xen call trace:
>>>> > (XEN)    [<ffff82c4801535a9>] pci_enable_msi+0x4c9/0x580
>>>> > (XEN)    [<ffff82c480154832>] map_domain_pirq+0x242/0x2f0
>>>> > (XEN)    [<ffff82c4801ede5f>] compat_physdev_op+0xc8f/0x1010
>>>> > (XEN)    [<ffff82c4801ef863>] compat_hypercall+0x83/0x90
>>>> > (XEN)
>>>> > (XEN) Pagetable walk from ffff82c3ffeb614d:
>>>> > (XEN)  L4[0x105] = 00000000bf4e2027 5555555555555555
>>>> > (XEN)  L3[0x10f] = 00000000bf698063 5555555555555555
>>>> > (XEN)  L2[0x1ff] = 00000000bf697063 5555555555555555
>>>> > (XEN)  L1[0x0b6] = f5861e4a00100173 ffffffffffffffff
>>>> > (XEN)
>>>> > (XEN) ****************************************
>>>> > (XEN) Panic on CPU 15:
>>>> > (XEN) FATAL PAGE FAULT
>>>> > (XEN) [error_code=000b]
>>>> > (XEN) Faulting linear address: ffff82c3ffeb614d
>>>> > (XEN) ****************************************
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>>  Sander                            mailto:linux@eikelenboom.it
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>
>>_______________________________________________
>>Xen-devel mailing list
>>Xen-devel@lists.xensource.com
>>http://lists.xensource.com/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-25 10:48         ` George Dunlap
@ 2010-02-25 10:56           ` Jan Beulich
  2010-02-25 11:46             ` George Dunlap
  0 siblings, 1 reply; 26+ messages in thread
From: Jan Beulich @ 2010-02-25 10:56 UTC (permalink / raw)
  To: George Dunlap, Yunhong Jiang; +Cc: Sander Eikelenboom, xen-devel

>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 11:48 >>>
>Is it possible that there's actually a bug in the compat code, and
>that table_base actually *was* set to (uint32_t)1?  If a reasonable
>number for table_base is "1", giving it 64 bits in the structure would
>seem a bit like overkill...

"1" definitely is not a reasonable value here. And it's also not the
compat code I'm sure - it is the kernel using a bad structure definition.

Jan

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-25 10:56           ` Jan Beulich
@ 2010-02-25 11:46             ` George Dunlap
  2010-02-25 12:13               ` George Dunlap
  2010-02-25 13:10               ` Jan Beulich
  0 siblings, 2 replies; 26+ messages in thread
From: George Dunlap @ 2010-02-25 11:46 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Sander Eikelenboom, Yunhong Jiang, xen-devel

I'm looking at the debian source package for this kernel to see if I
can sort out where it got the header from.

Given that this is already in a major distribution, is there any way
we can fail gracefully if someone's running this kernel?  I'm not
familiar enough with the MSI to know if this is possible, or what a
good set of "sanity checks" would be for failing the hypercall.

 -George

On Thu, Feb 25, 2010 at 10:56 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 11:48 >>>
>>Is it possible that there's actually a bug in the compat code, and
>>that table_base actually *was* set to (uint32_t)1?  If a reasonable
>>number for table_base is "1", giving it 64 bits in the structure would
>>seem a bit like overkill...
>
> "1" definitely is not a reasonable value here. And it's also not the
> compat code I'm sure - it is the kernel using a bad structure definition.
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-25 11:46             ` George Dunlap
@ 2010-02-25 12:13               ` George Dunlap
  2010-02-25 13:07                 ` Jan Beulich
  2010-02-26  1:42                 ` Jiang, Yunhong
  2010-02-25 13:10               ` Jan Beulich
  1 sibling, 2 replies; 26+ messages in thread
From: George Dunlap @ 2010-02-25 12:13 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Sander Eikelenboom, Jeremy Fitzhardinge, Yunhong Jiang, xen-devel

(Jeremy: Discussing the default Lenny dom0 package, 2.6.26-2-xen--686
crashing during boot if MSIs are available.)

Sure enough, the structure it's using looks like this:

struct physdev_map_pirq {
    domid_t domid;
    /* IN */
    int type;
    /* IN */
    int index;
    /* IN or OUT */
    int pirq;
    /* IN */
    struct {
        int bus, devfn, entry_nr;
        int msi;  /* 0 - MSIX    1 - MSI */
    } msi_info;
};

The code in question came from a patch called
suse-20080808143035.patch; reading the numbers as the timestamp "2008
August 8" would seem to match up with the 3.3 dev lifecycle.

Any suggestions for a simple fix I can try to push upstream?

 -George

On Thu, Feb 25, 2010 at 11:46 AM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> I'm looking at the debian source package for this kernel to see if I
> can sort out where it got the header from.
>
> Given that this is already in a major distribution, is there any way
> we can fail gracefully if someone's running this kernel?  I'm not
> familiar enough with the MSI to know if this is possible, or what a
> good set of "sanity checks" would be for failing the hypercall.
>
>  -George
>
> On Thu, Feb 25, 2010 at 10:56 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 11:48 >>>
>>>Is it possible that there's actually a bug in the compat code, and
>>>that table_base actually *was* set to (uint32_t)1?  If a reasonable
>>>number for table_base is "1", giving it 64 bits in the structure would
>>>seem a bit like overkill...
>>
>> "1" definitely is not a reasonable value here. And it's also not the
>> compat code I'm sure - it is the kernel using a bad structure definition.
>>
>> Jan
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel  (2.6.26-2-xen-686)
  2010-02-25 12:13               ` George Dunlap
@ 2010-02-25 13:07                 ` Jan Beulich
  2010-02-25 13:19                   ` Sander Eikelenboom
  2010-02-25 13:28                   ` George Dunlap
  2010-02-26  1:42                 ` Jiang, Yunhong
  1 sibling, 2 replies; 26+ messages in thread
From: Jan Beulich @ 2010-02-25 13:07 UTC (permalink / raw)
  To: George Dunlap
  Cc: Sander Eikelenboom, Jeremy Fitzhardinge, Yunhong Jiang, xen-devel

>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 13:13 >>>
>Any suggestions for a simple fix I can try to push upstream?

I'm afraid not (other than simply disabling at least the MSI-X part of
the code), as it would require table_base to be initialized properly.

Jan

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel  (2.6.26-2-xen-686)
  2010-02-25 11:46             ` George Dunlap
  2010-02-25 12:13               ` George Dunlap
@ 2010-02-25 13:10               ` Jan Beulich
  1 sibling, 0 replies; 26+ messages in thread
From: Jan Beulich @ 2010-02-25 13:10 UTC (permalink / raw)
  To: George Dunlap; +Cc: Sander Eikelenboom, Yunhong Jiang, xen-devel

>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 12:46 >>>
>Given that this is already in a major distribution, is there any way
>we can fail gracefully if someone's running this kernel?  I'm not
>familiar enough with the MSI to know if this is possible, or what a
>good set of "sanity checks" would be for failing the hypercall.

Checking for a suitably aligned and within PADDR_BITS range would
certainly be doable, but I question the sense. Such a check would
prevent the crash, but it wouldn't guarantee the system would work
(and may result in more subtle crashes).

Jan

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-25 13:07                 ` Jan Beulich
@ 2010-02-25 13:19                   ` Sander Eikelenboom
  2010-02-25 13:24                     ` Pasi Kärkkäinen
  2010-02-25 13:43                     ` Jan Beulich
  2010-02-25 13:28                   ` George Dunlap
  1 sibling, 2 replies; 26+ messages in thread
From: Sander Eikelenboom @ 2010-02-25 13:19 UTC (permalink / raw)
  To: Jan Beulich; +Cc: George Dunlap, Jeremy Fitzhardinge, Yunhong Jiang, xen-devel

Does the 2.6.18.8-xen linux tree require pci=nomsi ?
Or was is something introduced after 2.6.18 ?

The debian/novell forward ported kernels are all based on the 2.6.18.8 patches, and some extra patches by the distributions.
So shouldn't it be some specific patch applied to only the debian tree ?

Thursday, February 25, 2010, 2:07:29 PM, you wrote:

>>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 13:13 >>>
>>Any suggestions for a simple fix I can try to push upstream?

> I'm afraid not (other than simply disabling at least the MSI-X part of
> the code), as it would require table_base to be initialized properly.

> Jan




-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-25 13:19                   ` Sander Eikelenboom
@ 2010-02-25 13:24                     ` Pasi Kärkkäinen
  2010-02-25 13:43                     ` Jan Beulich
  1 sibling, 0 replies; 26+ messages in thread
From: Pasi Kärkkäinen @ 2010-02-25 13:24 UTC (permalink / raw)
  To: Sander Eikelenboom
  Cc: George Dunlap, Jeremy Fitzhardinge, Yunhong Jiang, xen-devel,
	Jan Beulich

On Thu, Feb 25, 2010 at 02:19:30PM +0100, Sander Eikelenboom wrote:
> Does the 2.6.18.8-xen linux tree require pci=nomsi ?
> Or was is something introduced after 2.6.18 ?
> 

This bug doesn't exist in 2.6.18-xen or in the current novell forwardports, afaik.
It only exists in the snapshot that debian uses in their 2.6.26-*-xen kernels.

> The debian/novell forward ported kernels are all based on the 2.6.18.8 patches, and some extra patches by the distributions.
> So shouldn't it be some specific patch applied to only the debian tree ?
> 

Yes, the bugfix patch is only needed in the debian 2.6.26 tree.

-- Pasi

> Thursday, February 25, 2010, 2:07:29 PM, you wrote:
> 
> >>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 13:13 >>>
> >>Any suggestions for a simple fix I can try to push upstream?
> 
> > I'm afraid not (other than simply disabling at least the MSI-X part of
> > the code), as it would require table_base to be initialized properly.
> 
> > Jan
> 
> 
> 
> 
> -- 
> Best regards,
>  Sander                            mailto:linux@eikelenboom.it
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-25 13:07                 ` Jan Beulich
  2010-02-25 13:19                   ` Sander Eikelenboom
@ 2010-02-25 13:28                   ` George Dunlap
  2010-02-26 11:05                     ` George Dunlap
  1 sibling, 1 reply; 26+ messages in thread
From: George Dunlap @ 2010-02-25 13:28 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Sander Eikelenboom, Jeremy Fitzhardinge, Yunhong Jiang, xen-devel

Forward porting the linux-2.6.18 patch has been straightforward so
far... I'm going to give it a spin and see if it actually boots. :-)

It's linux-2.6.18.hg c/s 645:359b1e70d9eb, in case you're interested.

 -George

On Thu, Feb 25, 2010 at 1:07 PM, Jan Beulich <JBeulich@novell.com> wrote:
>>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 13:13 >>>
>>Any suggestions for a simple fix I can try to push upstream?
>
> I'm afraid not (other than simply disabling at least the MSI-X part of
> the code), as it would require table_base to be initialized properly.
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel  (2.6.26-2-xen-686)
  2010-02-25 13:19                   ` Sander Eikelenboom
  2010-02-25 13:24                     ` Pasi Kärkkäinen
@ 2010-02-25 13:43                     ` Jan Beulich
  2010-02-25 14:05                       ` Pasi Kärkkäinen
  1 sibling, 1 reply; 26+ messages in thread
From: Jan Beulich @ 2010-02-25 13:43 UTC (permalink / raw)
  To: Sander Eikelenboom
  Cc: George Dunlap, Jeremy Fitzhardinge, Yunhong Jiang, xen-devel

>>> Sander Eikelenboom <linux@eikelenboom.it> 25.02.10 14:19 >>>
>So shouldn't it be some specific patch applied to only the debian tree ?

Based on the patch file name George reported, I think much rather a
patch that later wasn't updated as needed...

Jan

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel  (2.6.26-2-xen-686)
  2010-02-25 13:43                     ` Jan Beulich
@ 2010-02-25 14:05                       ` Pasi Kärkkäinen
  0 siblings, 0 replies; 26+ messages in thread
From: Pasi Kärkkäinen @ 2010-02-25 14:05 UTC (permalink / raw)
  To: Jan Beulich
  Cc: George Dunlap, Sander Eikelenboom, Jeremy Fitzhardinge,
	Yunhong Jiang, xen-devel

On Thu, Feb 25, 2010 at 01:43:53PM +0000, Jan Beulich wrote:
> >>> Sander Eikelenboom <linux@eikelenboom.it> 25.02.10 14:19 >>>
> >So shouldn't it be some specific patch applied to only the debian tree ?
> 
> Based on the patch file name George reported, I think much rather a
> patch that later wasn't updated as needed...
> 

Yeah, I don't think the Debian 2.6.26 kernel Xen patch has been updated
after the initial drop in 2008..

-- Pasi

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: Crash during boot in Debian lenny default dom0 kernel  (2.6.26-2-xen-686)
  2010-02-25 12:13               ` George Dunlap
  2010-02-25 13:07                 ` Jan Beulich
@ 2010-02-26  1:42                 ` Jiang, Yunhong
  2010-02-26 10:55                   ` George Dunlap
  2010-02-26 10:56                   ` George Dunlap
  1 sibling, 2 replies; 26+ messages in thread
From: Jiang, Yunhong @ 2010-02-26  1:42 UTC (permalink / raw)
  To: George Dunlap, Jan Beulich
  Cc: Sander Eikelenboom, Jeremy Fitzhardinge, xen-devel

Hmm, this issue is caused because of changeset 18323, which extend the physdev_map_pirq strucutre. IIRC, this is mainly for SR-IOV support, that Xen can't get the MMIO BAR from the virtual device.

However, dig into futher, I suspect if we need to change the definition of 'struct physdev_op'. Currently there is no maxium length limit, should it have something like the "pad" in struct xen_platform_op?
One possibility is, if one new type physdev operation added, which extend the length of struct physdev_op, it may cause issue (like copy_from_guest in do_physdev_op failed randomly). 
But I have no idea of how to add the padd without breaking compatibility.

--jyh

@@ -136,10 +136,13 @@ struct physdev_map_pirq {
     /* IN or OUT */
     int pirq;
     /* IN */
-    struct {
-        int bus, devfn, entry_nr;
-       int msi;  /* 0 - MSIX    1 - MSI */
-    } msi_info;
+    int bus;
+    /* IN */
+    int devfn;
+    /* IN */
+    int entry_nr;
+    /* IN */
+    uint64_t table_base;


>-----Original Message-----
>From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of George
>Dunlap
>Sent: Thursday, February 25, 2010 8:14 PM
>To: Jan Beulich
>Cc: Jiang, Yunhong; Sander Eikelenboom; xen-devel@lists.xensource.com; Jeremy
>Fitzhardinge
>Subject: Re: [Xen-devel] Crash during boot in Debian lenny default dom0 kernel
>(2.6.26-2-xen-686)
>
>(Jeremy: Discussing the default Lenny dom0 package, 2.6.26-2-xen--686
>crashing during boot if MSIs are available.)
>
>Sure enough, the structure it's using looks like this:
>
>struct physdev_map_pirq {
>    domid_t domid;
>    /* IN */
>    int type;
>    /* IN */
>    int index;
>    /* IN or OUT */
>    int pirq;
>    /* IN */
>    struct {
>        int bus, devfn, entry_nr;
>        int msi;  /* 0 - MSIX    1 - MSI */
>    } msi_info;
>};
>
>The code in question came from a patch called
>suse-20080808143035.patch; reading the numbers as the timestamp "2008
>August 8" would seem to match up with the 3.3 dev lifecycle.
>
>Any suggestions for a simple fix I can try to push upstream?
>
> -George
>
>On Thu, Feb 25, 2010 at 11:46 AM, George Dunlap
><George.Dunlap@eu.citrix.com> wrote:
>> I'm looking at the debian source package for this kernel to see if I
>> can sort out where it got the header from.
>>
>> Given that this is already in a major distribution, is there any way
>> we can fail gracefully if someone's running this kernel?  I'm not
>> familiar enough with the MSI to know if this is possible, or what a
>> good set of "sanity checks" would be for failing the hypercall.
>>
>>  -George
>>
>> On Thu, Feb 25, 2010 at 10:56 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 11:48 >>>
>>>>Is it possible that there's actually a bug in the compat code, and
>>>>that table_base actually *was* set to (uint32_t)1?  If a reasonable
>>>>number for table_base is "1", giving it 64 bits in the structure would
>>>>seem a bit like overkill...
>>>
>>> "1" definitely is not a reasonable value here. And it's also not the
>>> compat code I'm sure - it is the kernel using a bad structure definition.
>>>
>>> Jan
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-26  1:42                 ` Jiang, Yunhong
@ 2010-02-26 10:55                   ` George Dunlap
  2010-02-26 10:56                   ` George Dunlap
  1 sibling, 0 replies; 26+ messages in thread
From: George Dunlap @ 2010-02-26 10:55 UTC (permalink / raw)
  To: Jiang, Yunhong
  Cc: Sander Eikelenboom, Jeremy Fitzhardinge, xen-devel, Jan Beulich

Jiang, Yunhong wrote:
> Hmm, this issue is caused because of changeset 18323, which extend the physdev_map_pirq strucutre. IIRC, this is mainly for SR-IOV support, that Xen can't get the MMIO BAR from the virtual device.
>
> However, dig into futher, I suspect if we need to change the definition of 'struct physdev_op'. Currently there is no maxium length limit, should it have something like the "pad" in struct xen_platform_op?
>   
The padding isn't the problem; the problem is that Xen is expecting an 
address in there, but it's getting "garbage + {0,1}".  As Jan pointed 
out, how is Xen supposed to distinguish an address from garbage + 
incorrect parameter?

At any rate, I have a patch to the debian kernel I'll post in a bit.

 -George

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-26  1:42                 ` Jiang, Yunhong
  2010-02-26 10:55                   ` George Dunlap
@ 2010-02-26 10:56                   ` George Dunlap
  1 sibling, 0 replies; 26+ messages in thread
From: George Dunlap @ 2010-02-26 10:56 UTC (permalink / raw)
  To: Jiang, Yunhong
  Cc: Sander Eikelenboom, Jeremy Fitzhardinge, xen-devel, Jan Beulich

Jiang, Yunhong wrote:
> Hmm, this issue is caused because of changeset 18323, which extend the physdev_map_pirq strucutre. IIRC, this is mainly for SR-IOV support, that Xen can't get the MMIO BAR from the virtual device.
>
> However, dig into futher, I suspect if we need to change the definition of 'struct physdev_op'. Currently there is no maxium length limit, should it have something like the "pad" in struct xen_platform_op?
>   
The padding isn't the problem; the problem is that Xen is expecting an 
address in there, but it's getting "garbage + {0,1}".  As Jan pointed 
out, how is Xen supposed to distinguish an address from garbage + 
incorrect parameter?

At any rate, I have a patch to the debian kernel I'll post in a bit.

 -George

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-25 13:28                   ` George Dunlap
@ 2010-02-26 11:05                     ` George Dunlap
  2010-02-26 11:14                       ` Sander Eikelenboom
  0 siblings, 1 reply; 26+ messages in thread
From: George Dunlap @ 2010-02-26 11:05 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Sander Eikelenboom, Jeremy Fitzhardinge, Yunhong Jiang, xen-devel

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

OK, the attached patch fits cleanly in to the debian source package
infrastructure and can result in a built .deb file that actually
works.

Can those who know the system take a quick look to see if there's
anything obviously broken?  I'll file a bug report to debian with the
patch Monday; hopefully it will be picked up quickly.

Thanks,
 -George

On Thu, Feb 25, 2010 at 1:28 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> Forward porting the linux-2.6.18 patch has been straightforward so
> far... I'm going to give it a spin and see if it actually boots. :-)
>
> It's linux-2.6.18.hg c/s 645:359b1e70d9eb, in case you're interested.
>
>  -George
>
> On Thu, Feb 25, 2010 at 1:07 PM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 13:13 >>>
>>>Any suggestions for a simple fix I can try to push upstream?
>>
>> I'm afraid not (other than simply disabling at least the MSI-X part of
>> the code), as it would require table_base to be initialized properly.
>>
>> Jan
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>

[-- Attachment #2: fix-msi-hypercall.patch --]
[-- Type: text/x-patch, Size: 4894 bytes --]

diff -u -r build_i386_xen_686/drivers/pci/msi-xen.c build_i386_xen_686-fix/drivers/pci/msi-xen.c
--- build_i386_xen_686/drivers/pci/msi-xen.c	2010-02-25 12:23:43.000000000 +0000
+++ build_i386_xen_686-fix/drivers/pci/msi-xen.c	2010-02-25 13:08:16.000000000 +0000
@@ -238,11 +238,27 @@
 	return 0;
 }
 
+static u64 find_table_base(struct pci_dev *dev, int pos)
+{
+	u8 bar;
+	u32 reg;
+	unsigned long flags;
+
+ 	pci_read_config_dword(dev, msix_table_offset_reg(pos), &reg);
+	bar = reg & PCI_MSIX_FLAGS_BIRMASK;
+
+	flags = pci_resource_flags(dev, bar);
+	if (flags & (IORESOURCE_DISABLED | IORESOURCE_UNSET | IORESOURCE_BUSY))
+		return 0;
+
+	return pci_resource_start(dev, bar);
+}
+
 /*
  * Protected by msi_lock
  */
 static int msi_map_pirq_to_vector(struct pci_dev *dev, int pirq,
-                                  int entry_nr, int msi)
+				  int entry_nr, u64 table_base)
 {
 	struct physdev_map_pirq map_irq;
 	int rc;
@@ -254,10 +270,10 @@
 	map_irq.type = MAP_PIRQ_TYPE_MSI;
 	map_irq.index = -1;
 	map_irq.pirq = pirq;
-    map_irq.msi_info.bus = dev->bus->number;
-    map_irq.msi_info.devfn = dev->devfn;
-	map_irq.msi_info.entry_nr = entry_nr;
-    map_irq.msi_info.msi = msi;
+	map_irq.bus = dev->bus->number;
+	map_irq.devfn = dev->devfn;
+	map_irq.entry_nr = entry_nr;
+	map_irq.table_base = table_base;
 
 	if ((rc = HYPERVISOR_physdev_op(PHYSDEVOP_map_pirq, &map_irq)))
 		printk(KERN_WARNING "map irq failed\n");
@@ -268,9 +284,9 @@
 	return map_irq.pirq;
 }
 
-static int msi_map_vector(struct pci_dev *dev, int entry_nr, int msi)
+static int msi_map_vector(struct pci_dev *dev, int entry_nr, u64 table_base)
 {
-	return msi_map_pirq_to_vector(dev, -1, entry_nr, msi);
+	return msi_map_pirq_to_vector(dev, -1, entry_nr, table_base);
 }
 
 static void pci_intx_for_msi(struct pci_dev *dev, int enable)
@@ -286,7 +302,7 @@
 	if (!dev->msi_enabled)
 		return;
 
-	pirq = msi_map_pirq_to_vector(dev, dev->irq, 0, 1);
+	pirq = msi_map_pirq_to_vector(dev, dev->irq, 0, 0);
 	if (pirq < 0)
 		return;
 
@@ -296,19 +312,29 @@
 
 static void __pci_restore_msix_state(struct pci_dev *dev)
 {
+        int pos;
 	unsigned long flags;
+	u64 table_base;
 	struct msi_dev_list *msi_dev_entry;
 	struct msi_pirq_entry *pirq_entry, *tmp;
 
+	pos = pci_find_capability(dev, PCI_CAP_ID_MSIX);
+	if (pos <= 0)
+	  return;
+
 	if (!dev->msix_enabled)
 		return;
 
 	msi_dev_entry = get_msi_dev_pirq_list(dev);
+	table_base = find_table_base(dev, pos);
+	if (!table_base)
+		return;
 
 	spin_lock_irqsave(&msi_dev_entry->pirq_list_lock, flags);
 	list_for_each_entry_safe(pirq_entry, tmp,
-							 &msi_dev_entry->pirq_list_head, list)
-		msi_map_pirq_to_vector(dev, pirq_entry->pirq, pirq_entry->entry_nr, 0);
+				 &msi_dev_entry->pirq_list_head, list)
+		msi_map_pirq_to_vector(dev, pirq_entry->pirq,
+				       pirq_entry->entry_nr, table_base);
 	spin_unlock_irqrestore(&msi_dev_entry->pirq_list_lock, flags);
 
 	pci_intx_for_msi(dev, 0);
@@ -338,10 +364,10 @@
 
 	msi_set_enable(dev, 0);	/* Ensure msi is disabled as I set it up */
 
-   	pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
+	pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
 	pci_read_config_word(dev, msi_control_reg(pos), &control);
 
-	pirq = msi_map_vector(dev, 0, 1);
+	pirq = msi_map_vector(dev, 0, 0);
 	if (pirq < 0)
 		return -EBUSY;
 
@@ -367,7 +393,8 @@
 static int msix_capability_init(struct pci_dev *dev,
 				struct msix_entry *entries, int nvec)
 {
-	int pirq, i, j, mapped;
+        u64 table_base;
+	int pirq, i, j, mapped, pos;
 	struct msi_dev_list *msi_dev_entry = get_msi_dev_pirq_list(dev);
 	struct msi_pirq_entry *pirq_entry;
 
@@ -376,6 +403,11 @@
 
 	msix_set_enable(dev, 0);/* Ensure msix is disabled as I set it up */
 
+	pos = pci_find_capability(dev, PCI_CAP_ID_MSIX);
+	table_base = find_table_base(dev, pos);
+	if (!table_base)
+		return -ENODEV;
+
 	/* MSI-X Table Initialization */
 	for (i = 0; i < nvec; i++) {
 		mapped = 0;
@@ -392,7 +424,7 @@
 		}
 		if (mapped)
 			continue;
-		pirq = msi_map_vector(dev, entries[i].entry, 0);
+		pirq = msi_map_vector(dev, entries[i].entry, table_base);
 		if (pirq < 0)
 			break;
 		attach_pirq_entry(pirq, entries[i].entry, msi_dev_entry);
diff -u -r build_i386_xen_686/include/xen/interface/physdev.h build_i386_xen_686-fix/include/xen/interface/physdev.h
--- build_i386_xen_686/include/xen/interface/physdev.h	2010-02-25 12:23:43.000000000 +0000
+++ build_i386_xen_686-fix/include/xen/interface/physdev.h	2010-02-25 12:38:42.000000000 +0000
@@ -136,10 +136,13 @@
     /* IN or OUT */
     int pirq;
     /* IN */
-    struct {
-        int bus, devfn, entry_nr;
-		int msi;  /* 0 - MSIX    1 - MSI */
-    } msi_info;
+    int bus;
+    /* IN */
+    int devfn;
+    /* IN */
+    int entry_nr;
+    /* IN */
+    uint64_t table_base;
 };
 typedef struct physdev_map_pirq physdev_map_pirq_t;
 DEFINE_XEN_GUEST_HANDLE(physdev_map_pirq_t);

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-26 11:05                     ` George Dunlap
@ 2010-02-26 11:14                       ` Sander Eikelenboom
  2010-02-26 11:21                         ` George Dunlap
  0 siblings, 1 reply; 26+ messages in thread
From: Sander Eikelenboom @ 2010-02-26 11:14 UTC (permalink / raw)
  To: George Dunlap; +Cc: Jeremy Fitzhardinge, Yunhong Jiang, xen-devel, Jan Beulich

For what I remember from the past, the debian packages automatically put pci=nomsi in grub etc.
So perhaps it's wise to get that workaround removed as well.

--
Sander


Friday, February 26, 2010, 12:05:48 PM, you wrote:

> OK, the attached patch fits cleanly in to the debian source package
> infrastructure and can result in a built .deb file that actually
> works.

> Can those who know the system take a quick look to see if there's
> anything obviously broken?  I'll file a bug report to debian with the
> patch Monday; hopefully it will be picked up quickly.

> Thanks,
>  -George

> On Thu, Feb 25, 2010 at 1:28 PM, George Dunlap
> <George.Dunlap@eu.citrix.com> wrote:
>> Forward porting the linux-2.6.18 patch has been straightforward so
>> far... I'm going to give it a spin and see if it actually boots. :-)
>>
>> It's linux-2.6.18.hg c/s 645:359b1e70d9eb, in case you're interested.
>>
>>  -George
>>
>> On Thu, Feb 25, 2010 at 1:07 PM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 13:13 >>>
>>>>Any suggestions for a simple fix I can try to push upstream?
>>>
>>> I'm afraid not (other than simply disabling at least the MSI-X part of
>>> the code), as it would require table_base to be initialized properly.
>>>
>>> Jan
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>



-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-26 11:14                       ` Sander Eikelenboom
@ 2010-02-26 11:21                         ` George Dunlap
  2010-02-26 12:04                           ` Pasi Kärkkäinen
  0 siblings, 1 reply; 26+ messages in thread
From: George Dunlap @ 2010-02-26 11:21 UTC (permalink / raw)
  To: Sander Eikelenboom
  Cc: Jeremy Fitzhardinge, Yunhong Jiang, xen-devel, Jan Beulich

Do they?  I've installed Lenny in 2 boxes recently (within the last 2 
months), and neither has the pci=nomsi in the grub config.  I'm pretty 
sure I would have remembered removing it.  It's also not in the 
"xenkopt=" automagic kernel configuration.

I did install from a local mirror, but I've updated since then...

 -George

Sander Eikelenboom wrote:
> For what I remember from the past, the debian packages automatically put pci=nomsi in grub etc.
> So perhaps it's wise to get that workaround removed as well.
>
> --
> Sander
>
>
> Friday, February 26, 2010, 12:05:48 PM, you wrote:
>
>   
>> OK, the attached patch fits cleanly in to the debian source package
>> infrastructure and can result in a built .deb file that actually
>> works.
>>     
>
>   
>> Can those who know the system take a quick look to see if there's
>> anything obviously broken?  I'll file a bug report to debian with the
>> patch Monday; hopefully it will be picked up quickly.
>>     
>
>   
>> Thanks,
>>  -George
>>     
>
>   
>> On Thu, Feb 25, 2010 at 1:28 PM, George Dunlap
>> <George.Dunlap@eu.citrix.com> wrote:
>>     
>>> Forward porting the linux-2.6.18 patch has been straightforward so
>>> far... I'm going to give it a spin and see if it actually boots. :-)
>>>
>>> It's linux-2.6.18.hg c/s 645:359b1e70d9eb, in case you're interested.
>>>
>>>  -George
>>>
>>> On Thu, Feb 25, 2010 at 1:07 PM, Jan Beulich <JBeulich@novell.com> wrote:
>>>       
>>>>>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 13:13 >>>
>>>>>>>               
>>>>> Any suggestions for a simple fix I can try to push upstream?
>>>>>           
>>>> I'm afraid not (other than simply disabling at least the MSI-X part of
>>>> the code), as it would require table_base to be initialized properly.
>>>>
>>>> Jan
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>>>
>>>>         
>
>
>
>   

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-26 11:21                         ` George Dunlap
@ 2010-02-26 12:04                           ` Pasi Kärkkäinen
  2010-02-26 12:26                             ` Sander Eikelenboom
  0 siblings, 1 reply; 26+ messages in thread
From: Pasi Kärkkäinen @ 2010-02-26 12:04 UTC (permalink / raw)
  To: George Dunlap
  Cc: Sander Eikelenboom, Jeremy Fitzhardinge, Yunhong Jiang,
	xen-devel, Jan Beulich

On Fri, Feb 26, 2010 at 11:21:14AM +0000, George Dunlap wrote:
> Do they?  I've installed Lenny in 2 boxes recently (within the last 2  
> months), and neither has the pci=nomsi in the grub config.  I'm pretty  
> sure I would have remembered removing it.  It's also not in the  
> "xenkopt=" automagic kernel configuration.
>
> I did install from a local mirror, but I've updated since then...
>

Yeah, pci=nomsi is not there as a default in Lenny.

-- Pasi

> -George
>
> Sander Eikelenboom wrote:
>> For what I remember from the past, the debian packages automatically put pci=nomsi in grub etc.
>> So perhaps it's wise to get that workaround removed as well.
>>
>> --
>> Sander
>>
>>
>> Friday, February 26, 2010, 12:05:48 PM, you wrote:
>>
>>   
>>> OK, the attached patch fits cleanly in to the debian source package
>>> infrastructure and can result in a built .deb file that actually
>>> works.
>>>     
>>
>>   
>>> Can those who know the system take a quick look to see if there's
>>> anything obviously broken?  I'll file a bug report to debian with the
>>> patch Monday; hopefully it will be picked up quickly.
>>>     
>>
>>   
>>> Thanks,
>>>  -George
>>>     
>>
>>   
>>> On Thu, Feb 25, 2010 at 1:28 PM, George Dunlap
>>> <George.Dunlap@eu.citrix.com> wrote:
>>>     
>>>> Forward porting the linux-2.6.18 patch has been straightforward so
>>>> far... I'm going to give it a spin and see if it actually boots. :-)
>>>>
>>>> It's linux-2.6.18.hg c/s 645:359b1e70d9eb, in case you're interested.
>>>>
>>>>  -George
>>>>
>>>> On Thu, Feb 25, 2010 at 1:07 PM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>       
>>>>>>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 13:13 >>>
>>>>>>>>               
>>>>>> Any suggestions for a simple fix I can try to push upstream?
>>>>>>           
>>>>> I'm afraid not (other than simply disabling at least the MSI-X part of
>>>>> the code), as it would require table_base to be initialized properly.
>>>>>
>>>>> Jan
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/xen-devel
>>>>>
>>>>>         
>>
>>
>>
>>   
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)
  2010-02-26 12:04                           ` Pasi Kärkkäinen
@ 2010-02-26 12:26                             ` Sander Eikelenboom
  0 siblings, 0 replies; 26+ messages in thread
From: Sander Eikelenboom @ 2010-02-26 12:26 UTC (permalink / raw)
  To: Pasi Kärkkäinen
  Cc: George Dunlap, Jeremy Fitzhardinge, Yunhong Jiang, xen-devel,
	Jan Beulich

Hmm seems I was wrong, perhaps i have added it myself to the kopt, just can't remember it 


Friday, February 26, 2010, 1:04:21 PM, you wrote:

> On Fri, Feb 26, 2010 at 11:21:14AM +0000, George Dunlap wrote:
>> Do they?  I've installed Lenny in 2 boxes recently (within the last 2  
>> months), and neither has the pci=nomsi in the grub config.  I'm pretty  
>> sure I would have remembered removing it.  It's also not in the  
>> "xenkopt=" automagic kernel configuration.
>>
>> I did install from a local mirror, but I've updated since then...
>>

> Yeah, pci=nomsi is not there as a default in Lenny.

> -- Pasi

>> -George
>>
>> Sander Eikelenboom wrote:
>>> For what I remember from the past, the debian packages automatically put pci=nomsi in grub etc.
>>> So perhaps it's wise to get that workaround removed as well.
>>>
>>> --
>>> Sander
>>>
>>>
>>> Friday, February 26, 2010, 12:05:48 PM, you wrote:
>>>
>>>   
>>>> OK, the attached patch fits cleanly in to the debian source package
>>>> infrastructure and can result in a built .deb file that actually
>>>> works.
>>>>     
>>>
>>>   
>>>> Can those who know the system take a quick look to see if there's
>>>> anything obviously broken?  I'll file a bug report to debian with the
>>>> patch Monday; hopefully it will be picked up quickly.
>>>>     
>>>
>>>   
>>>> Thanks,
>>>>  -George
>>>>     
>>>
>>>   
>>>> On Thu, Feb 25, 2010 at 1:28 PM, George Dunlap
>>>> <George.Dunlap@eu.citrix.com> wrote:
>>>>     
>>>>> Forward porting the linux-2.6.18 patch has been straightforward so
>>>>> far... I'm going to give it a spin and see if it actually boots. :-)
>>>>>
>>>>> It's linux-2.6.18.hg c/s 645:359b1e70d9eb, in case you're interested.
>>>>>
>>>>>  -George
>>>>>
>>>>> On Thu, Feb 25, 2010 at 1:07 PM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>       
>>>>>>>>> George Dunlap <George.Dunlap@eu.citrix.com> 25.02.10 13:13 >>>
>>>>>>>>>               
>>>>>>> Any suggestions for a simple fix I can try to push upstream?
>>>>>>>           
>>>>>> I'm afraid not (other than simply disabling at least the MSI-X part of
>>>>>> the code), as it would require table_base to be initialized properly.
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xen-devel mailing list
>>>>>> Xen-devel@lists.xensource.com
>>>>>> http://lists.xensource.com/xen-devel
>>>>>>
>>>>>>         
>>>
>>>
>>>
>>>   
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel



-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2010-02-26 12:26 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-24 18:47 Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686) George Dunlap
2010-02-24 19:08 ` Sander Eikelenboom
2010-02-24 20:20   ` Pasi Kärkkäinen
2010-02-24 23:57     ` George Dunlap
2010-02-25  6:50       ` Jiang, Yunhong
2010-02-25 10:48         ` George Dunlap
2010-02-25 10:56           ` Jan Beulich
2010-02-25 11:46             ` George Dunlap
2010-02-25 12:13               ` George Dunlap
2010-02-25 13:07                 ` Jan Beulich
2010-02-25 13:19                   ` Sander Eikelenboom
2010-02-25 13:24                     ` Pasi Kärkkäinen
2010-02-25 13:43                     ` Jan Beulich
2010-02-25 14:05                       ` Pasi Kärkkäinen
2010-02-25 13:28                   ` George Dunlap
2010-02-26 11:05                     ` George Dunlap
2010-02-26 11:14                       ` Sander Eikelenboom
2010-02-26 11:21                         ` George Dunlap
2010-02-26 12:04                           ` Pasi Kärkkäinen
2010-02-26 12:26                             ` Sander Eikelenboom
2010-02-26  1:42                 ` Jiang, Yunhong
2010-02-26 10:55                   ` George Dunlap
2010-02-26 10:56                   ` George Dunlap
2010-02-25 13:10               ` Jan Beulich
2010-02-25  9:16       ` Jan Beulich
2010-02-25  9:28         ` Jiang, Yunhong

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.