I''m running Fedora 12 (kernel 2.6.31.5-127.fc12.x86_64) on a Dell T7500 Xeon with VT-x and VT-d. After building xen-unstable and rebooting, the dom0 Linux hangs a few seconds after it gets control from Xen, and I have to power-cycle to recover. Here are the last messages before it hangs: [ 2.766882] loop: module loaded [ 2.767736] input: Macintosh mouse button emulation as /devices/virtual/input/input2 [ 2.769396] xen_set_ioapic_routing: irq 20 gsi 20 vector 20 ioapic 0 pin 20 triggering 1 polarity 1 [ 2.770342] achi 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20 [ 2.771158] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x27 impl SATA mode [ 2.772078] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pio ems <<hangs at this point>> Thoughts? Any grub parameters I should try for Linux and/or Xen? Any further info I can provide? Thanks, Ed _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-Feb-25 23:11 UTC
Re: [Xen-devel] Using xen-unstable, dom0 hangs during boot
On 02/25/2010 02:18 PM, Nadolski, Ed wrote:> I''m running Fedora 12 (kernel 2.6.31.5-127.fc12.x86_64) on a Dell T7500 Xeon with VT-x and VT-d. After building xen-unstable and rebooting, the dom0 Linux hangs a few seconds after it gets control from Xen, and I have to power-cycle to recover. Here are the last messages before it hangs: > > [ 2.766882] loop: module loaded > [ 2.767736] input: Macintosh mouse button emulation as /devices/virtual/input/input2 > [ 2.769396] xen_set_ioapic_routing: irq 20 gsi 20 vector 20 ioapic 0 pin 20 triggering 1 polarity 1 > [ 2.770342] achi 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20 > [ 2.771158] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x27 impl SATA mode > [ 2.772078] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pio ems > <<hangs at this point>> > > Thoughts? Any grub parameters I should try for Linux and/or Xen? Any further info I can provide? >What kernel is this? What''s the boot command line? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nadolski, Ed
2010-Feb-26 13:33 UTC
RE: [Xen-devel] Using xen-unstable, dom0 hangs during boot
> -----Original Message----- > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] > Sent: Thursday, February 25, 2010 4:12 PM > To: Nadolski, Ed > Cc: Xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Using xen-unstable, dom0 hangs during boot > > On 02/25/2010 02:18 PM, Nadolski, Ed wrote: > > I''m running Fedora 12 (kernel 2.6.31.5-127.fc12.x86_64) on a Dell > T7500 Xeon with VT-x and VT-d. After building xen-unstable and > rebooting, the dom0 Linux hangs a few seconds after it gets control > from Xen, and I have to power-cycle to recover. Here are the last > messages before it hangs: > > > > [ 2.766882] loop: module loaded > > [ 2.767736] input: Macintosh mouse button emulation as > /devices/virtual/input/input2 > > [ 2.769396] xen_set_ioapic_routing: irq 20 gsi 20 vector 20 ioapic > 0 pin 20 triggering 1 polarity 1 > > [ 2.770342] achi 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) - > > IRQ 20 > > [ 2.771158] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 > Gbps 0x27 impl SATA mode > > [ 2.772078] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pio > ems > > <<hangs at this point>> > > > > Thoughts? Any grub parameters I should try for Linux and/or Xen? > Any further info I can provide? > > > > What kernel is this? What''s the boot command line?The build downloaded the kernel from: + git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6-pvops.git.tmp The serial console output stops before the Linux kernel messages show up, but here is what I have in grub.conf: title Fedora12-Xen (2.6.31.6) Xen and dom0 serial console root (hd0,0) kernel /xen-4.0.0-rc4.gz com1=115200,8n1 console=com1 module /vmlinuz-2.6.31.6 ro root=UUID=d9c5bf5d-23d1-445e-9210-e6ad0798a0ba nomodeset LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=tty0 console=ttyS0,115200 module /initramfs-2.6.31.6.img but it still fails the same way regardless of the vmlinuz parameters. With the serial port enabled, the hang happens a bit sooner, at the serial driver init. Also, no change if I disable VTx/VTd in the BIOS. FWIW, I''ve attached the Xen serial output as well. Thanks, Ed Please stand by while rebooting the system... Restarting system. __ __ _ _ ___ ___ _ _ \ \/ /___ _ __ | || | / _ \ / _ \ _ __ ___| || | \ // _ \ ''_ \ | || |_| | | | | | |__| ''__/ __| || |_ / \ __/ | | | |__ _| |_| | |_| |__| | | (__|__ _| /_/\_\___|_| |_| |_|(_)___(_)___/ |_| \___| |_| (XEN) Xen version 4.0.0-rc4 (root@) (gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC) ) Thu Feb 25 22:09:19 MST 2010 (XEN) Latest ChangeSet: Thu Feb 25 21:03:26 2010 +0000 20983:94535cc63835 (XEN) Command line: com1=115200,8n1 console=com1 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009e400 (usable) (XEN) 00000000000f0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000dbdf9c00 (usable) (XEN) 00000000dbdf9c00 - 00000000dbe4bc00 (ACPI NVS) (XEN) 00000000dbe4bc00 - 00000000dbe4dc00 (ACPI data) (XEN) 00000000dbe4dc00 - 00000000dc000000 (reserved) (XEN) 00000000f8000000 - 00000000fd000000 (reserved) (XEN) 00000000fe000000 - 00000000fed00400 (reserved) (XEN) 00000000fee00000 - 00000000fef00000 (reserved) (XEN) 00000000ffb00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 00000001a4000000 (usable) (XEN) ACPI: RSDP 000FEBF0, 0024 (r2 DELL ) (XEN) ACPI: XSDT 000FCC3C, 0084 (r1 DELL B10K 15 ASL 61) (XEN) ACPI: FACP 000FCD34, 00F4 (r3 DELL B10K 15 ASL 61) (XEN) ACPI: DSDT FFE9A4EE, 5732 (r1 DELL dt_ex 1000 INTL 20050624) (XEN) ACPI: FACS DBDF9C00, 0040 (XEN) ACPI: SSDT FFE9FD41, 00AC (r1 DELL st_ex 1000 INTL 20050624) (XEN) ACPI: APIC 000FCE28, 016A (r1 DELL B10K 15 ASL 61) (XEN) ACPI: BOOT 000FCF92, 0028 (r1 DELL B10K 15 ASL 61) (XEN) ACPI: ASF! 000FCFBA, 0096 (r32 DELL B10K 15 ASL 61) (XEN) ACPI: MCFG 000FD050, 003E (r1 DELL B10K 15 ASL 61) (XEN) ACPI: HPET 000FD08E, 0038 (r1 DELL B10K 15 ASL 61) (XEN) ACPI: TCPA 000FD2EA, 0032 (r1 DELL B10K 15 ASL 61) (XEN) ACPI: DMAR 000FD31C, 00F8 (r1 DELL B10K 15 ASL 61) (XEN) ACPI: SLIC 000FD0C6, 0176 (r1 DELL B10K 15 ASL 61) (XEN) ACPI: _RAT 000FDECE, 0030 (r1 DELL B10K 15 ASL 61) (XEN) ACPI: SSDT DBE4DC00, 10F4 (r1 INTEL PPM RCM 80000001 INTL 20061109) (XEN) System RAM: 6105MB (6252368kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-00000001a4000000 (XEN) Domain heap initialised (XEN) DMI 2.5 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[dbdf9c0c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) Processor #0 7:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) Processor #2 7:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) (XEN) Processor #4 7:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) (XEN) Processor #6 7:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x01] disabled) (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x03] disabled) (XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x19] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC (acpi_id[0x20] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1]) (XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 (XEN) ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24]) (XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-47 (XEN) ACPI: IOAPIC (id[0x0a] address[0xfec88000] gsi_base[48]) (XEN) IOAPIC[2]: apic_id 10, version 32, address 0xfec88000, GSI 48-71 (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: Flat. Using 3 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 = dfffe000 (XEN) [VT-D]dmar.c:319: bridge: 20:3.0 start = 20 sec = 21 sub = 21 (XEN) [VT-D]dmar.c:319: bridge: 20:7.0 start = 20 sec = 22 sub = 22 (XEN) [VT-D]dmar.c:319: bridge: 20:9.0 start = 20 sec = 23 sub = 23 (XEN) [VT-D]dmar.c:646: found ACPI_DMAR_DRHD: (XEN) [VT-D]dmar.c:379: dmaru->address = fedc0000 (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: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:331: endpoint: 0:1d.7 (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:1a.7 (XEN) [VT-D]dmar.c:540: RMRR region: base_addr dbe58000 end_address dbe6ffff (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:3.0 start = 0 sec = 3 sub = 3 (XEN) [VT-D]dmar.c:319: bridge: 0:7.0 start = 0 sec = 4 sub = 4 (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: 20:3.0 start = 20 sec = 21 sub = 21 (XEN) [VT-D]dmar.c:319: bridge: 20:7.0 start = 20 sec = 22 sub = 22 (XEN) [VT-D]dmar.c:319: bridge: 20:9.0 start = 20 sec = 23 sub = 23 (XEN) PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 - 63 (XEN) PCI: MCFG area at f8000000 reserved in E820 (XEN) Using ACPI (MADT) for SMP configuration information (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Initializing CPU#0 (XEN) Detected 2128.066 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: 4096K (XEN) CPU: Physical Processor ID: 0 (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:1072: drhd->address = dfffe000 (XEN) [VT-D]iommu.c:1073: iommu->reg = ffff82c3fff57000 (XEN) [VT-D]iommu.c:1072: drhd->address = fedc0000 (XEN) [VT-D]iommu.c:1073: iommu->reg = ffff82c3fff56000 (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 not supported. (XEN) I/O virtualisation enabled (XEN) I/O virtualisation for PV guests disabled (XEN) CPU0: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz stepping 05 (XEN) Booting processor 1/2 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: 4096K (XEN) CPU: Physical Processor ID: 0 (XEN) CPU: Processor Core ID: 1 (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 E5506 @ 2.13GHz stepping 05 (XEN) Booting processor 2/4 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: 4096K (XEN) CPU: Physical Processor ID: 0 (XEN) CPU: Processor Core ID: 2 (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 E5506 @ 2.13GHz stepping 05 (XEN) Booting processor 3/6 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: 4096K (XEN) CPU: Physical Processor ID: 0 (XEN) CPU: Processor Core ID: 3 (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 E5506 @ 2.13GHz stepping 05 (XEN) Total of 4 processors activated. (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) microcode.c:73:d32767 microcode: CPU1 resumed (XEN) microcode.c:73:d32767 microcode: CPU2 resumed (XEN) Brought up 4 CPUs (XEN) microcode.c:73:d32767 microcode: CPU3 resumed (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:1309:d32767 domain_context_mapping:PCIe: bdf = 0:0.0 (XEN) [VT-D]iommu.c:1309: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:1309: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:1309: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:1316: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:1316: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:1316:d32767 domain_context_mapping:PCI: bdf = 0:1a.2 (XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1a.2: no extended config (XEN) [VT-D]iommu.c:1316: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:1316: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:1316: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:1316:d32767 domain_context_mapping:PCI: bdf = 0:1d.2 (XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1d.2: no extended config (XEN) [VT-D]iommu.c:1316: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:1316: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:1316:d32767 domain_context_mapping:PCI: bdf = 0:1f.2 (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 0:1f.3 (XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1f.3: no extended config (XEN) [VT-D]iommu.c:1309:d32767 domain_context_mapping:PCIe: bdf = 3:0.0 (XEN) [VT-D]iommu.c:1309:d32767 domain_context_mapping:PCIe: bdf = 6:0.0 (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 7:a.0 (XEN) [VT-D]mmconfig-shared.c:460: next cap:7:a.0: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 7:a.1 (XEN) [VT-D]mmconfig-shared.c:460: next cap:7:a.1: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 7:a.2 (XEN) [VT-D]mmconfig-shared.c:460: next cap:7:a.2: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 7:a.3 (XEN) [VT-D]mmconfig-shared.c:460: next cap:7:a.3: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 7:a.4 (XEN) [VT-D]mmconfig-shared.c:460: next cap:7:a.4: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 7:a.5 (XEN) [VT-D]mmconfig-shared.c:460: next cap:7:a.5: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 7:a.6 (XEN) [VT-D]mmconfig-shared.c:460: next cap:7:a.6: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 7:a.7 (XEN) [VT-D]mmconfig-shared.c:460: next cap:7:a.7: no extended config (XEN) [VT-D]iommu.c:1309:d32767 domain_context_mapping:PCIe: bdf = 20:14.0 (XEN) [VT-D]mmconfig-shared.c:460: next cap:20:14.0: no extended config (XEN) [VT-D]iommu.c:1309:d32767 domain_context_mapping:PCIe: bdf = 20:14.1 (XEN) [VT-D]mmconfig-shared.c:460: next cap:20:14.1: no extended config (XEN) [VT-D]iommu.c:1309:d32767 domain_context_mapping:PCIe: bdf = 20:14.2 (XEN) [VT-D]mmconfig-shared.c:460: next cap:20:14.2: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:0.0 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:0.0: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:0.1 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:0.1: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:2.0 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:2.0: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:2.1 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:2.1: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:2.4 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:2.4: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:2.5 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:2.5: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:3.0 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:3.0: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:3.1 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:3.1: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:3.2 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:3.2: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:3.4 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:3.4: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:4.0 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:4.0: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:4.1 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:4.1: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:4.2 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:4.2: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:4.3 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:4.3: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:5.0 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:5.0: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:5.1 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:5.1: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:5.2 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:5.2: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:5.3 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:5.3: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:6.0 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:6.0: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:6.1 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:6.1: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:6.2 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:6.2: no extended config (XEN) [VT-D]iommu.c:1316:d32767 domain_context_mapping:PCI: bdf = 3f:6.3 (XEN) [VT-D]mmconfig-shared.c:460: next cap:3f:6.3: no extended config (XEN) [VT-D]iommu.c:694: iommu_enable_translation: iommu->reg = ffff82c3fff57000 (XEN) [VT-D]iommu.c:694: iommu_enable_translation: iommu->reg = ffff82c3fff56000 (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x83b000 (XEN) elf_parse_binary: phdr: paddr=0x183b000 memsz=0xe68f8 (XEN) elf_parse_binary: phdr: paddr=0x1922000 memsz=0x888 (XEN) elf_parse_binary: phdr: paddr=0x1923000 memsz=0x15860 (XEN) elf_parse_binary: phdr: paddr=0x1938860 memsz=0x1a57a0 (XEN) elf_parse_binary: memory: 0x1000000 -> 0x1ade000 (XEN) elf_xen_parse_note: GUEST_OS = "linux" (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6" (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0" (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 (XEN) elf_xen_parse_note: ENTRY = 0xffffffff81938a60 (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81009000 (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb" (XEN) elf_xen_parse_note: PAE_MODE = "yes" (XEN) elf_xen_parse_note: LOADER = "generic" (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1 (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0 (XEN) elf_xen_addr_calc_check: addresses: (XEN) virt_base = 0xffffffff80000000 (XEN) elf_paddr_offset = 0x0 (XEN) virt_offset = 0xffffffff80000000 (XEN) virt_kstart = 0xffffffff81000000 (XEN) virt_kend = 0xffffffff81ade000 (XEN) virt_entry = 0xffffffff81938a60 (XEN) p2m_base = 0xffffffffffffffff (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1ade000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000198000000->000000019c000000 (1500633 pages to be allocated) (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81ade000 (XEN) Init. ramdisk: ffffffff81ade000->ffffffff827dce00 (XEN) Phys-Mach map: ffffffff827dd000->ffffffff8336fec8 (XEN) Start info: ffffffff83370000->ffffffff833704b4 (XEN) Page tables: ffffffff83371000->ffffffff83390000 (XEN) Boot stack: ffffffff83390000->ffffffff83391000 (XEN) TOTAL: ffffffff80000000->ffffffff83800000 (XEN) ENTRY ADDRESS: ffffffff81938a60 (XEN) Dom0 has maximum 4 VCPUs (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff8183b000 (XEN) elf_load_binary: phdr 1 at 0xffffffff8183b000 -> 0xffffffff819218f8 (XEN) elf_load_binary: phdr 2 at 0xffffffff81922000 -> 0xffffffff81922888 (XEN) elf_load_binary: phdr 3 at 0xffffffff81923000 -> 0xffffffff81938860 (XEN) elf_load_binary: phdr 4 at 0xffffffff81938860 -> 0xffffffff819b2000 (XEN) Scrubbing Free RAM: .done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times to switch input to Xen) (XEN) Freed 156kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... (XEN) io_apic.c:2291: (XEN) ioapic_guest_write: apic=0, pin=0, irq=0 (XEN) ioapic_guest_write: new_entry=00010900 (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=2, irq=0 (XEN) ioapic_guest_write: new_entry=00010900 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) irq.c:1445: dom0: pirq 0 or irq 3 already mapped (XEN) io_apic.c:2291: (XEN) ioapic_guest_write: apic=0, pin=4, irq=4 (XEN) ioapic_guest_write: new_entry=00010900 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) irq.c:1445: dom0: pirq 0 or irq 5 already mapped (XEN) irq.c:1445: dom0: pirq 0 or irq 6 already mapped (XEN) irq.c:1445: dom0: pirq 0 or irq 7 already mapped (XEN) irq.c:1445: dom0: pirq 0 or irq 8 already mapped (XEN) irq.c:1445: dom0: pirq 0 or irq 9 already mapped (XEN) irq.c:1445: dom0: pirq 0 or irq 10 already mapped (XEN) irq.c:1445: dom0: pirq 0 or irq 11 already mapped (XEN) irq.c:1445: dom0: pirq 0 or irq 12 already mapped (XEN) irq.c:1445: dom0: pirq 0 or irq 13 already mapped (XEN) irq.c:1445: dom0: pirq 0 or irq 14 already mapped (XEN) irq.c:1445: dom0: pirq 0 or irq 15 already mapped (XEN) allocated vector for irq:16 (XEN) irq.c:1445: dom0: pirq 0 or irq 16 already mapped (XEN) allocated vector for irq:17 (XEN) irq.c:1445: dom0: pirq 0 or irq 17 already mapped (XEN) allocated vector for irq:18 (XEN) irq.c:1445: dom0: pirq 0 or irq 18 already mapped (XEN) allocated vector for irq:19 (XEN) irq.c:1445: dom0: pirq 0 or irq 19 already mapped (XEN) allocated vector for irq:20 (XEN) irq.c:1445: dom0: pirq 0 or irq 20 already mapped (XEN) allocated vector for irq:21 (XEN) irq.c:1445: dom0: pirq 0 or irq 21 already mapped (XEN) allocated vector for irq:22 (XEN) irq.c:1445: dom0: pirq 0 or irq 22 already mapped (XEN) allocated vector for irq:23 (XEN) irq.c:1445: dom0: pirq 0 or irq 23 already mapped (XEN) allocated vector for irq:24 (XEN) irq.c:1445: dom0: pirq 0 or irq 24 already mapped (XEN) allocated vector for irq:25 (XEN) irq.c:1445: dom0: pirq 0 or irq 25 already mapped (XEN) allocated vector for irq:26 (XEN) irq.c:1445: dom0: pirq 0 or irq 26 already mapped (XEN) allocated vector for irq:27 (XEN) irq.c:1445: dom0: pirq 0 or irq 27 already mapped (XEN) allocated vector for irq:28 (XEN) irq.c:1445: dom0: pirq 0 or irq 28 already mapped (XEN) allocated vector for irq:29 (XEN) irq.c:1445: dom0: pirq 0 or irq 29 already mapped (XEN) allocated vector for irq:30 (XEN) irq.c:1445: dom0: pirq 0 or irq 30 already mapped (XEN) allocated vector for irq:31 (XEN) irq.c:1445: dom0: pirq 0 or irq 31 already mapped (XEN) allocated vector for irq:32 (XEN) irq.c:1445: dom0: pirq 0 or irq 32 already mapped (XEN) allocated vector for irq:33 (XEN) irq.c:1445: dom0: pirq 0 or irq 33 already mapped (XEN) allocated vector for irq:34 (XEN) irq.c:1445: dom0: pirq 0 or irq 34 already mapped (XEN) allocated vector for irq:35 (XEN) irq.c:1445: dom0: pirq 0 or irq 35 already mapped (XEN) allocated vector for irq:36 (XEN) irq.c:1445: dom0: pirq 0 or irq 36 already mapped (XEN) allocated vector for irq:37 (XEN) irq.c:1445: dom0: pirq 0 or irq 37 already mapped (XEN) allocated vector for irq:38 (XEN) irq.c:1445: dom0: pirq 0 or irq 38 already mapped (XEN) allocated vector for irq:39 (XEN) irq.c:1445: dom0: pirq 0 or irq 39 already mapped (XEN) allocated vector for irq:40 (XEN) irq.c:1445: dom0: pirq 0 or irq 40 already mapped (XEN) allocated vector for irq:41 (XEN) irq.c:1445: dom0: pirq 0 or irq 41 already mapped (XEN) allocated vector for irq:42 (XEN) irq.c:1445: dom0: pirq 0 or irq 42 already mapped (XEN) allocated vector for irq:43 (XEN) irq.c:1445: dom0: pirq 0 or irq 43 already mapped (XEN) allocated vector for irq:44 (XEN) irq.c:1445: dom0: pirq 0 or irq 44 already mapped (XEN) allocated vector for irq:45 (XEN) irq.c:1445: dom0: pirq 0 or irq 45 already mapped (XEN) allocated vector for irq:46 (XEN) irq.c:1445: dom0: pirq 0 or irq 46 already mapped (XEN) allocated vector for irq:47 (XEN) irq.c:1445: dom0: pirq 0 or irq 47 already mapped (XEN) allocated vector for irq:48 (XEN) irq.c:1445: dom0: pirq 0 or irq 48 already mapped (XEN) allocated vector for irq:49 (XEN) irq.c:1445: dom0: pirq 0 or irq 49 already mapped (XEN) allocated vector for irq:50 (XEN) irq.c:1445: dom0: pirq 0 or irq 50 already mapped (XEN) allocated vector for irq:51 (XEN) irq.c:1445: dom0: pirq 0 or irq 51 already mapped (XEN) allocated vector for irq:52 (XEN) irq.c:1445: dom0: pirq 0 or irq 52 already mapped (XEN) allocated vector for irq:53 (XEN) irq.c:1445: dom0: pirq 0 or irq 53 already mapped (XEN) allocated vector for irq:54 (XEN) irq.c:1445: dom0: pirq 0 or irq 54 already mapped (XEN) allocated vector for irq:55 (XEN) irq.c:1445: dom0: pirq 0 or irq 55 already mapped (XEN) allocated vector for irq:56 (XEN) irq.c:1445: dom0: pirq 0 or irq 56 already mapped (XEN) allocated vector for irq:57 (XEN) irq.c:1445: dom0: pirq 0 or irq 57 already mapped (XEN) allocated vector for irq:58 (XEN) irq.c:1445: dom0: pirq 0 or irq 58 already mapped (XEN) allocated vector for irq:59 (XEN) irq.c:1445: dom0: pirq 0 or irq 59 already mapped (XEN) allocated vector for irq:60 (XEN) irq.c:1445: dom0: pirq 0 or irq 60 already mapped (XEN) allocated vector for irq:61 (XEN) irq.c:1445: dom0: pirq 0 or irq 61 already mapped (XEN) allocated vector for irq:62 (XEN) irq.c:1445: dom0: pirq 0 or irq 62 already mapped (XEN) allocated vector for irq:63 (XEN) irq.c:1445: dom0: pirq 0 or irq 63 already mapped (XEN) allocated vector for irq:64 (XEN) irq.c:1445: dom0: pirq 0 or irq 64 already mapped (XEN) allocated vector for irq:65 (XEN) irq.c:1445: dom0: pirq 0 or irq 65 already mapped (XEN) allocated vector for irq:66 (XEN) irq.c:1445: dom0: pirq 0 or irq 66 already mapped (XEN) allocated vector for irq:67 (XEN) irq.c:1445: dom0: pirq 0 or irq 67 already mapped (XEN) allocated vector for irq:68 (XEN) irq.c:1445: dom0: pirq 0 or irq 68 already mapped (XEN) allocated vector for irq:69 (XEN) irq.c:1445: dom0: pirq 0 or irq 69 already mapped (XEN) allocated vector for irq:70 (XEN) irq.c:1445: dom0: pirq 0 or irq 70 already mapped (XEN) allocated vector for irq:71 (XEN) irq.c:1445: dom0: pirq 0 or irq 71 already mapped (XEN) io_apic.c:2291: (XEN) ioapic_guest_write: apic=0, pin=0, irq=0 (XEN) ioapic_guest_write: new_entry=00000900 (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=00000904 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) PCI add device 00:00.0 (XEN) PCI add device 00:01.0 (XEN) PCI add device 00:03.0 (XEN) PCI add device 00:07.0 (XEN) PCI add device 00:14.0 (XEN) PCI add device 00:14.1 (XEN) PCI add device 00:14.2 (XEN) PCI add device 00:1a.0 (XEN) PCI add device 00:1a.1 (XEN) PCI add device 00:1a.2 (XEN) PCI add device 00:1a.7 (XEN) PCI add device 00:1c.0 (XEN) PCI add device 00:1c.5 (XEN) PCI add device 00:1d.0 (XEN) PCI add device 00:1d.1 (XEN) PCI add device 00:1d.2 (XEN) PCI add device 00:1d.7 (XEN) PCI add device 00:1e.0 (XEN) PCI add device 00:1f.0 (XEN) PCI add device 00:1f.2 (XEN) PCI add device 00:1f.3 (XEN) PCI add device 01:00.0 (XEN) PCI add device 03:00.0 (XEN) PCI add device 06:00.0 (XEN) PCI add device 07:0a.0 (XEN) PCI add device 20:03.0 (XEN) PCI add device 20:07.0 (XEN) PCI add device 20:09.0 (XEN) PCI add device 20:14.0 (XEN) PCI add device 20:14.1 (XEN) PCI add device 20:14.2 (XEN) io_apic.c:2291: (XEN) ioapic_guest_write: apic=0, pin=4, irq=4 (XEN) ioapic_guest_write: new_entry=00000904 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) Set CPU acpi_id(1) cpuid(0) Px State info: (XEN) _PPC: 0 (XEN) Set CPU acpi_id(1) cpuid(0) Px State info: (XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=64, bit_offset=0, reserved=0, address=409 (XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=16, bit_offset=0, reserved=0, address=408 (XEN) _PSS: state_count=5 (XEN) State0: 2128MHz 80000mW 10us 10us 0x10 0x10 (XEN) State1: 1995MHz 66000mW 10us 10us 0xf 0xf (XEN) State2: 1862MHz 55000mW 10us 10us 0xe 0xe (XEN) State3: 1729MHz 45000mW 10us 10us 0xd 0xd (XEN) State4: 1596MHz 37000mW 10us 10us 0xc 0xc (XEN) _PSD: num_entries=5 rev=0 domain=0 coord_type=254 num_processors=4 (XEN) _PPC: 0 (XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space (XEN) max_freq: 2128000 second_max_freq: 1995000 (XEN) CPU 0 initialization completed (XEN) Set CPU acpi_id(2) cpuid(1) Px State info: (XEN) _PPC: 0 (XEN) Set CPU acpi_id(2) cpuid(1) Px State info: (XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=64, bit_offset=0, reserved=0, address=409 (XEN) _PCT: descriptor=130, <<serial output stop here, but linux kernel boots, then hangs at serial driver init>> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2010-Feb-26 14:46 UTC
Re: [Xen-devel] Using xen-unstable, dom0 hangs during boot
On Fri, Feb 26, 2010 at 06:33:27AM -0700, Nadolski, Ed wrote:> > -----Original Message----- > > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] > > Sent: Thursday, February 25, 2010 4:12 PM > > To: Nadolski, Ed > > Cc: Xen-devel@lists.xensource.com > > Subject: Re: [Xen-devel] Using xen-unstable, dom0 hangs during boot > > > > On 02/25/2010 02:18 PM, Nadolski, Ed wrote: > > > I''m running Fedora 12 (kernel 2.6.31.5-127.fc12.x86_64) on a Dell > > T7500 Xeon with VT-x and VT-d. After building xen-unstable and > > rebooting, the dom0 Linux hangs a few seconds after it gets control > > from Xen, and I have to power-cycle to recover. Here are the last > > messages before it hangs: > > > > > > [ 2.766882] loop: module loaded > > > [ 2.767736] input: Macintosh mouse button emulation as > > /devices/virtual/input/input2 > > > [ 2.769396] xen_set_ioapic_routing: irq 20 gsi 20 vector 20 ioapic > > 0 pin 20 triggering 1 polarity 1 > > > [ 2.770342] achi 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) - > > > IRQ 20 > > > [ 2.771158] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 > > Gbps 0x27 impl SATA mode > > > [ 2.772078] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pio > > ems > > > <<hangs at this point>> > > > > > > Thoughts? Any grub parameters I should try for Linux and/or Xen? > > Any further info I can provide? > > > > > > > What kernel is this? What''s the boot command line? > > The build downloaded the kernel from: > > + git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6-pvops.git.tmp > > The serial console output stops before the Linux kernel messages show up, but here is what I have in grub.conf: > > title Fedora12-Xen (2.6.31.6) Xen and dom0 serial console > root (hd0,0) > kernel /xen-4.0.0-rc4.gz com1=115200,8n1 console=com1 > module /vmlinuz-2.6.31.6 ro root=UUID=d9c5bf5d-23d1-445e-9210-e6ad0798a0ba nomodeset LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=tty0 console=ttyS0,115200 > module /initramfs-2.6.31.6.img > > but it still fails the same way regardless of the vmlinuz parameters. With the serial port enabled, the hang happens a bit sooner, at the serial driver init. Also, no change if I disable VTx/VTd in the BIOS. >You should use grub configuration like this: title pv_ops dom0 with a serial console root (hd0,0) kernel /xen-4.0.0-rc4.gz dom0_mem=1024M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1 console=com1 module /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset module /initrd-2.6.31.6.img Modify the root parameter etc for your environment. Note that vmlinuz (dom0 kernel) needs to have "console=hvc0 earlyprintk=xen" to log to a serial console through Xen. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nadolski, Ed
2010-Feb-26 20:40 UTC
RE: [Xen-devel] Using xen-unstable, dom0 hangs during boot
> -----Original Message----- > From: Pasi Kärkkäinen [mailto:pasik@iki.fi] > Sent: Friday, February 26, 2010 7:46 AM > To: Nadolski, Ed > Cc: Jeremy Fitzhardinge; Xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Using xen-unstable, dom0 hangs during boot > > On Fri, Feb 26, 2010 at 06:33:27AM -0700, Nadolski, Ed wrote: > > > -----Original Message----- > > > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] > > > Sent: Thursday, February 25, 2010 4:12 PM > > > To: Nadolski, Ed > > > Cc: Xen-devel@lists.xensource.com > > > Subject: Re: [Xen-devel] Using xen-unstable, dom0 hangs during boot > > > > > > On 02/25/2010 02:18 PM, Nadolski, Ed wrote: > > > > I''m running Fedora 12 (kernel 2.6.31.5-127.fc12.x86_64) on a Dell > > > T7500 Xeon with VT-x and VT-d. After building xen-unstable and > > > rebooting, the dom0 Linux hangs a few seconds after it gets control > > > from Xen, and I have to power-cycle to recover. Here are the last > > > messages before it hangs: > > > > > > > > [ 2.766882] loop: module loaded > > > > [ 2.767736] input: Macintosh mouse button emulation as > > > /devices/virtual/input/input2 > > > > [ 2.769396] xen_set_ioapic_routing: irq 20 gsi 20 vector 20 > ioapic > > > 0 pin 20 triggering 1 polarity 1 > > > > [ 2.770342] achi 0000:00:1f.2: PCI INT C -> GSI 20 (level, > low) - > > > > IRQ 20 > > > > [ 2.771158] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports > 3 > > > Gbps 0x27 impl SATA mode > > > > [ 2.772078] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo > pio > > > ems > > > > <<hangs at this point>> > > > > > > > > Thoughts? Any grub parameters I should try for Linux and/or Xen? > > > Any further info I can provide? > > > > > > > > > > What kernel is this? What''s the boot command line? > > > > The build downloaded the kernel from: > > > > + git clone > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6- > pvops.git.tmp > > > > The serial console output stops before the Linux kernel messages show > up, but here is what I have in grub.conf: > > > > title Fedora12-Xen (2.6.31.6) Xen and dom0 serial console > > root (hd0,0) > > kernel /xen-4.0.0-rc4.gz com1=115200,8n1 console=com1 > > module /vmlinuz-2.6.31.6 ro root=UUID=d9c5bf5d-23d1-445e- > 9210-e6ad0798a0ba nomodeset LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 > KEYBOARDTYPE=pc KEYTABLE=us console=tty0 console=ttyS0,115200 > > module /initramfs-2.6.31.6.img > > > > but it still fails the same way regardless of the vmlinuz parameters. > With the serial port enabled, the hang happens a bit sooner, at the > serial driver init. Also, no change if I disable VTx/VTd in the BIOS. > > > > You should use grub configuration like this: > > title pv_ops dom0 with a serial console > root (hd0,0) > kernel /xen-4.0.0-rc4.gz dom0_mem=1024M loglvl=all > guest_loglvl=all sync_console console_to_ring com1=115200,8n1 > console=com1 > module /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 > earlyprintk=xen nomodeset > module /initrd-2.6.31.6.img > > Modify the root parameter etc for your environment. > > Note that vmlinuz (dom0 kernel) needs to have "console=hvc0 > earlyprintk=xen" > to log to a serial console through Xen. > > -- PasiThanks Pasi. I''ve attached the full trace, and a few select lines are below. Any further thoughts? I''m not familiar with the interrupt mapping code, but I''ll see if there are some parameters I can change. Ed (XEN) Xen version 4.0.0-rc4 (root@) (gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC) ) Thu Feb 25 22:09:19 MST 2010 (XEN) Latest ChangeSet: Thu Feb 25 21:03:26 2010 +0000 20983:94535cc63835 (XEN) Console output is synchronous. (XEN) Command line: loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1 console=com1 ... Xen: setup ISA identity maps about to get started... [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 2.6.31.6 (root@truckee) (gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC) ) #1 SMP Thu Feb 25 22:00:24 MST 2010 [ 0.000000] Command line: ro root=UUID=d9c5bf5d-23d1-445e-9210-e6ad0798a0ba nomodeset LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=hvc0 earlyprintk=xen ... (XEN) CPU 3 initialization completed [ 5.888385] Event-channel device installed. [ 5.896414] blktap_device_init: blktap device major 253 [ 5.901550] blktap_ring_init: blktap ring major: 251 [ 5.907640] registering netback [ 5.918012] hpet_acpi_add: no address or irqs in _CRS [ 5.923249] Non-volatile memory driver v1.3 [ 5.927418] Linux agpgart interface v0.103 [ 5.931762] [drm] Initialized drm 1.1.0 20060810 [ 5.936338] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled (XEN) irq.c:1182:d0 Cannot bind IRQ 0 to guest. Will not share with others. << output stops here >> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nadolski, Ed
2010-Feb-28 23:47 UTC
RE: [Xen-devel] Using xen-unstable, dom0 hangs during boot
> -----Original Message-----On 02/25/2010 02:18 PM, Nadolski, Ed wrote:> I''m running Fedora 12 (kernel 2.6.31.5-127.fc12.x86_64) on a Dell T7500 Xeon with VT-x and VT-d. After building xen-unstable and rebooting, the dom0 Linux hangs a few seconds after it gets control from Xen, and I have to power-cycle to recover. Here are the last messages before it hangs: > > [ 2.766882] loop: module loaded > [ 2.767736] input: Macintosh mouse button emulation as /devices/virtual/input/input2 > [ 2.769396] xen_set_ioapic_routing: irq 20 gsi 20 vector 20 ioapic 0 pin 20 triggering 1 polarity 1 > [ 2.770342] achi 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20 > [ 2.771158] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x27 impl SATA mode > [ 2.772078] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pio ems > <<hangs at this point>>I''ve added a bunch of trace prints. With serial ports enabled for trace capture, the hang actually occurs earlier than the ahci code above. It now occurs during the serial8250_config_port() function in the 8250/16650 serial driver initialization. There is a call to probe_irq_on(), which calls msleep(20), but the msleep() never returns. (see below) If I hit the power button on the front panel, it generates an interrupt that forces the msleep() to return. Also, if I replace the msleep(20) with mdelay(20), the code does not hang at that point. (In either case, the code does hang again a short while later.) I''m not too familiar with kernel internals - what could cause the msleep() not to return? Possibly an interrupt gets missed, or is not getting unmasked? Thanks again, Ed /root/xen/xen-unstable.hg/linux-2.6-pvops.git/kernel/irq/autoprobe.c: /** * probe_irq_on - begin an interrupt autodetect * * Commence probing for an interrupt. The interrupts are scanned * and a mask of potential interrupt lines is returned. * */ unsigned long probe_irq_on(void) { struct irq_desc *desc; unsigned long mask = 0; unsigned int status; int i; /* * quiesce the kernel, or at least the asynchronous portion */ async_synchronize_full(); mutex_lock(&probing_active); /* * something may have generated an irq long ago and we want to * flush such a longstanding irq before considering it as spurious. */ for_each_irq_desc_reverse(i, desc) { spin_lock_irq(&desc->lock); if (!desc->action && !(desc->status & IRQ_NOPROBE)) { /* * An old-style architecture might still have * the handle_bad_irq handler there: */ compat_irq_chip_set_default_handler(desc); /* * Some chips need to know about probing in * progress: */ if (desc->chip->set_type) desc->chip->set_type(i, IRQ_TYPE_PROBE); desc->chip->startup(i); } spin_unlock_irq(&desc->lock); } /* Wait for longstanding interrupts to trigger. */ msleep(20); <== NEVER RETURNS (until power button is hit) /* * enable any unassigned irqs * (we must startup again here because if a longstanding irq * happened in the previous stage, it may have masked itself) */ for_each_irq_desc_reverse(i, desc) { spin_lock_irq(&desc->lock); if (!desc->action && !(desc->status & IRQ_NOPROBE)) { desc->status |= IRQ_AUTODETECT | IRQ_WAITING; if (desc->chip->startup(i)) desc->status |= IRQ_PENDING; } spin_unlock_irq(&desc->lock); } /* * Wait for spurious interrupts to trigger */ msleep(100); <== ALSO HANGS HERE AND NEVER RETURNS until power button is hit. /* * Now filter out any obviously spurious interrupts */ for_each_irq_desc(i, desc) { spin_lock_irq(&desc->lock); status = desc->status; if (status & IRQ_AUTODETECT) { /* It triggered already - consider it spurious. */ if (!(status & IRQ_WAITING)) { desc->status = status & ~IRQ_AUTODETECT; desc->chip->shutdown(i); } else if (i < 32) mask |= 1 << i; } spin_unlock_irq(&desc->lock); } return mask; } EXPORT_SYMBOL(probe_irq_on); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2010-Mar-01 15:10 UTC
Re: [Xen-devel] Using xen-unstable, dom0 hangs during boot
On Sun, Feb 28, 2010 at 04:47:21PM -0700, Nadolski, Ed wrote:> > -----Original Message----- > On 02/25/2010 02:18 PM, Nadolski, Ed wrote: > > I''m running Fedora 12 (kernel 2.6.31.5-127.fc12.x86_64) on a Dell T7500 Xeon with VT-x and VT-d. After building xen-unstable and rebooting, the dom0 Linux hangs a few seconds after it gets control from Xen, and I have to power-cycle to recover. Here are the last messages before it hangs: > > > > [ 2.766882] loop: module loaded > > [ 2.767736] input: Macintosh mouse button emulation as /devices/virtual/input/input2 > > [ 2.769396] xen_set_ioapic_routing: irq 20 gsi 20 vector 20 ioapic 0 pin 20 triggering 1 polarity 1 > > [ 2.770342] achi 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20 > > [ 2.771158] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x27 impl SATA mode > > [ 2.772078] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pio ems > > <<hangs at this point>> > > > > I''ve added a bunch of trace prints. With serial ports enabled for trace capture, the hang actually occurs earlier than the ahci code above. It now occurs during the serial8250_config_port() function in the 8250/16650 serial driver initialization. There is a call to probe_irq_on(), which calls msleep(20), but the msleep() never returns. (see below) > > If I hit the power button on the front panel, it generates an interrupt that forces the msleep() to return. Also, if I replace the msleep(20) with mdelay(20), the code does not hang at that point. (In either case, the code does hang again a short while later.) > > I''m not too familiar with kernel internals - what could cause the msleep() not to return? Possibly an interrupt gets missed, or is not getting unmasked?I think you are hot on the trail. Try hitting ''i'' (or maybe it is ''I'') and see what Xen prints out for the IRQ mapping. Earlier on you mentioned that you saw: "Xen: Cannot share IRQ0 with guest." which is a bit strange, considering you are booting Dom0. IRQ0 is usually the timer, but it looks as if the serial port is on interrupt 0? It shouldn''t be - try adding some more printk''s and find out what IRQ it thinks it is. Also try to boot the kernel without Xen and see what IRQ the serial port driver uses then. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nadolski, Ed
2010-Mar-02 19:23 UTC
[Xen-devel] dom0 hang in xen-4.0.0-rc5 - possible acpi issue? [WAS: Using xen-unstable, dom0 hangs during boot]
> -----Original Message----- > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Monday, March 01, 2010 8:10 AM > To: Nadolski, Ed > Cc: Pasi Kärkkäinen; Jeremy Fitzhardinge; Xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Using xen-unstable, dom0 hangs during boot > > On Sun, Feb 28, 2010 at 04:47:21PM -0700, Nadolski, Ed wrote: > > > -----Original Message----- > > On 02/25/2010 02:18 PM, Nadolski, Ed wrote: > > > I''m running Fedora 12 (kernel 2.6.31.5-127.fc12.x86_64) on a Dell > T7500 Xeon with VT-x and VT-d. After building xen-unstable and > rebooting, the dom0 Linux hangs a few seconds after it gets control > from Xen, and I have to power-cycle to recover. Here are the last > messages before it hangs: > > > > > > [ 2.766882] loop: module loaded > > > [ 2.767736] input: Macintosh mouse button emulation as > /devices/virtual/input/input2 > > > [ 2.769396] xen_set_ioapic_routing: irq 20 gsi 20 vector 20 > ioapic 0 pin 20 triggering 1 polarity 1 > > > [ 2.770342] achi 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) > -> IRQ 20 > > > [ 2.771158] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 > Gbps 0x27 impl SATA mode > > > [ 2.772078] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pio > ems > > > <<hangs at this point>> > > > > > > > > I''ve added a bunch of trace prints. With serial ports enabled for > trace capture, the hang actually occurs earlier than the ahci code > above. It now occurs during the serial8250_config_port() function in > the 8250/16650 serial driver initialization. There is a call to > probe_irq_on(), which calls msleep(20), but the msleep() never returns. > (see below) > > > > If I hit the power button on the front panel, it generates an > interrupt that forces the msleep() to return. Also, if I replace the > msleep(20) with mdelay(20), the code does not hang at that point. (In > either case, the code does hang again a short while later.) > > > > I''m not too familiar with kernel internals - what could cause the > msleep() not to return? Possibly an interrupt gets missed, or is not > getting unmasked? > > I think you are hot on the trail. Try hitting ''i'' (or maybe it is ''I'') > and see what Xen prints out for the IRQ mapping. Earlier on you > mentioned that you saw: "Xen: Cannot share IRQ0 with guest." which is a > bit strange, considering you are booting Dom0. IRQ0 is usually the > timer, but it looks as if the serial port is on interrupt 0? It > shouldn''t be - try adding some more printk''s and find out what IRQ it > thinks it is. > > Also try to boot the kernel without Xen and see what IRQ the serial > port driver uses then.I''ve found out a bit more. First, I''ve upgraded to Xen 4.0.0-rc5, but the problem persists. I''ve pasted some more trace below, including a WARN_ON() before the call to msleep(). The jumps in the timestamps show where msleep() hung and I hit the power button to force it to resume. Looks like the serial8250 driver gets IRQ 3 for ttyS1. I''m not clear what the "will not share" message for IRQ 0 means -- maybe it means Xen won''t allow the IRQ to be shared with a guest? It seems to happen in a loop that is initializing all the IRQs, not just the IRQ for the serial port. Interestingly, I can make the hang go away by specifying "acpi_skip_timer_override" to xen in grub.conf. AFAICT this is meant for some BIOS issues, but I don''t think this system has a problem BIOS, since it cleanly boots Xen 3.4.1 & CentOS 5.3 dom0 without acpi_skip_timer_override. Does that sound like maybe some kind of issue in the recent ACPI code? Would that be in Xen or in the dom0 Linux? Thanks again, Ed Here is the partial trace, full trace is attached: (XEN) Xen version 4.0.0-rc5 (root@) (gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC) ) Mon Mar 1 12:55:52 MST 2010 (XEN) Latest ChangeSet: Mon Mar 01 16:50:30 2010 +0000 20990:46bfb4a318e9 (XEN) Console output is synchronous. (XEN) Command line: loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1 console=com1 .... [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 2.6.31.6 (root@truckee) (gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC) ) #3 SMP Mon Mar 1 12:54:12 MST 2010 [ 0.000000] Command line: ro root=UUID=d9c5bf5d-23d1-445e-9210-e6ad0798a0ba nomodeset LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=hvc0 earlyprintk=xen [ 0.000000] KERNEL supported cpus: .... [ 5.936124] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 5.942676] probe_irq_on: ENTRY! (XEN) irq.c:1182:d0 Cannot bind IRQ 0 to guest. Will not share with others. [ 5.952512] ------------[ cut here ]------------ [ 5.957180] WARNING: at /root/xen/xen-unstable.hg/linux-2.6-pvops.git/kernel/irq/autoprobe.c:69 probe_irq_on+0xb3/0x213() [ 5.968172] Hardware name: Precision WorkStation T7500 [ 5.973537] Modules linked in: [ 5.976648] Pid: 1, comm: swapper Not tainted 2.6.31.6 #3 [ 5.982105] Call Trace: [ 5.984618] [<ffffffff8106938f>] warn_slowpath_common+0x77/0x8f [ 5.990670] [<ffffffff810693b6>] warn_slowpath_null+0xf/0x11 [ 5.996467] [<ffffffff810ae040>] probe_irq_on+0xb3/0x213 [ 6.001926] [<ffffffff812c79a9>] serial8250_config_port+0x781/0x98d [ 6.008324] [<ffffffff812c3ed6>] uart_add_one_port+0x11d/0x301 [ 6.014298] [<ffffffff811f3b3d>] ? kobject_init+0x43/0x83 [ 6.019842] [<ffffffff81961a24>] serial8250_init+0xfe/0x143 [ 6.025546] [<ffffffff81961926>] ? serial8250_init+0x0/0x143 [ 6.031347] [<ffffffff8100a087>] do_one_initcall+0x59/0x179 [ 6.037058] [<ffffffff81938f7a>] kernel_init+0x16f/0x1c5 [ 6.042515] [<ffffffff81033d6a>] child_rip+0xa/0x20 [ 6.047528] [<ffffffff81032f27>] ? int_ret_from_sys_call+0x7/0x1b [ 6.053760] [<ffffffff810336dd>] ? retint_restore_args+0x5/0x6 [ 6.059731] [<ffffffff81033d60>] ? child_rip+0x0/0x20 [ 6.064930] ---[ end trace 11878b47d03d9332 ]--- [ 6.069595] probe_irq_on: calling msleep(20) <<<HANGS, PRESS POWER BUTTON>>>> [ 60.833667] probe_irq_on: Returned from msleep(20) (XEN) irq.c:1182:d0 Cannot bind IRQ 0 to guest. Will not share with others. [ 60.845033] probe_irq_on: calling msleep(100) <<<HANGS, PRESS POWER BUTTON>>>> [ 76.386382] probe_irq_on: Returned from msleep(100) [ 76.391279] probe_irq_on: EXIT! [ 76.394535] probe_irq_on: ENTRY! (XEN) irq.c:1182:d0 Cannot bind IRQ 0 to guest. Will not share with others. [ 76.404698] ------------[ cut here ]------------ [ 76.409360] WARNING: at /root/xen/xen-unstable.hg/linux-2.6-pvops.git/kernel/irq/autoprobe.c:69 probe_irq_on+0xb3/0x213() [ 76.420351] Hardware name: Precision WorkStation T7500 [ 76.425718] Modules linked in: [ 76.428830] Pid: 1, comm: swapper Tainted: G W 2.6.31.6 #3 [ 76.435059] Call Trace: [ 76.437577] [<ffffffff8106938f>] warn_slowpath_common+0x77/0x8f [ 76.443630] [<ffffffff810693b6>] warn_slowpath_null+0xf/0x11 [ 76.449428] [<ffffffff810ae040>] probe_irq_on+0xb3/0x213 [ 76.454885] [<ffffffff812c79e2>] serial8250_config_port+0x7ba/0x98d [ 76.461285] [<ffffffff812c3ed6>] uart_add_one_port+0x11d/0x301 [ 76.467257] [<ffffffff811f3b3d>] ? kobject_init+0x43/0x83 [ 76.472800] [<ffffffff81961a24>] serial8250_init+0xfe/0x143 [ 76.478506] [<ffffffff81961926>] ? serial8250_init+0x0/0x143 [ 76.484305] [<ffffffff8100a087>] do_one_initcall+0x59/0x179 [ 76.490016] [<ffffffff81938f7a>] kernel_init+0x16f/0x1c5 [ 76.495473] [<ffffffff81033d6a>] child_rip+0xa/0x20 [ 76.500488] [<ffffffff81032f27>] ? int_ret_from_sys_call+0x7/0x1b [ 76.506720] [<ffffffff810336dd>] ? retint_restore_args+0x5/0x6 [ 76.512691] [<ffffffff81033d60>] ? child_rip+0x0/0x20 [ 76.517886] ---[ end trace 11878b47d03d9333 ]--- [ 76.522554] probe_irq_on: calling msleep(20) <<<HANGS, PRESS POWER BUTTON>>>> [ 109.284906] probe_irq_on: Returned from msleep(20) (XEN) irq.c:1182:d0 Cannot bind IRQ 0 to guest. Will not share with others. [ 109.296271] probe_irq_on: calling msleep(100) <<<HANGS, PRESS POWER BUTTON>>>> [ 111.941064] probe_irq_on: Returned from msleep(100) [ 111.945863] probe_irq_on: EXIT! [ 111.949166] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A [ 111.956146] 00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A [ 111.964407] brd: module loaded [ 111.968666] loop: module loaded [ 111.971867] input: Macintosh mouse button emulation as /devices/virtual/input/input2 [ 111.980123] xen_set_ioapic_routing: irq 20 gsi 20 vector 20 ioapic 0 pin 20 triggering 1 polarity 1 [ 111.989062] ahci 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20 [ 111.996048] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x27 impl SATA mode [ 112.004121] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pio ems <<<HANGS>>> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2010-Mar-03 18:18 UTC
Re: [Xen-devel] dom0 hang in xen-4.0.0-rc5 - possible acpi issue? [WAS: Using xen-unstable, dom0 hangs during boot]
> I''ve found out a bit more. First, I''ve upgraded to Xen 4.0.0-rc5, but the problem persists.Bummer..> > I''ve pasted some more trace below, including a WARN_ON() before the call to msleep(). The jumps in the timestamps show where msleep() hung and I hit the power button to force it to resume. > > Looks like the serial8250 driver gets IRQ 3 for ttyS1. I''m not clear what the "will not share" message for IRQ 0 means -- maybe it means Xen won''t allow the IRQ to be shared with a guest? It seems to happen in a loop that is initializing all the IRQs, not just the IRQ for the serial port. > > Interestingly, I can make the hang go away by specifying "acpi_skip_timer_override" to xen in grub.conf. AFAICT this is meant for some BIOS issues, but I don''t think this system has a problem BIOS, since it cleanly boots Xen 3.4.1 & CentOS 5.3 dom0 without acpi_skip_timer_override. Does that sound like maybe some kind of issue in the recent ACPI code? Would that be in Xen or in the dom0 Linux?Well, to be fair, 5.3 is a bit ancient. And since then the ACPI code in 2.6.31 handles much more - it might be that you are hitting something new. I don''t remember, but did you try just booting bare-metal with the pv-ops kernel? No Xen, just pv-ops by itself. Did it boot but without the serial console? Also can you try booting the kernel with Xen, with ''initcall_debug'' for your kernel command line? That "Xen: Cannot share IRQ0 with guest" is troubling me and I want to have an idea what part of the kernel code triggers this. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nadolski, Ed
2010-Mar-15 14:59 UTC
RE: [Xen-devel] dom0 hang in xen-4.0.0-rc5 - possible acpi issue? [WAS: Using xen-unstable, dom0 hangs during boot]
> -----Original Message----- > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Wednesday, March 03, 2010 11:19 AM > To: Nadolski, Ed > Cc: Pasi Kärkkäinen; Jeremy Fitzhardinge; Xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] dom0 hang in xen-4.0.0-rc5 - possible acpi > issue? [WAS: Using xen-unstable, dom0 hangs during boot] > > > I''ve found out a bit more. First, I''ve upgraded to Xen 4.0.0-rc5, > but the problem persists. > > Bummer.. > > > > I''ve pasted some more trace below, including a WARN_ON() before the > call to msleep(). The jumps in the timestamps show where msleep() hung > and I hit the power button to force it to resume. > > > > Looks like the serial8250 driver gets IRQ 3 for ttyS1. I''m not clear > what the "will not share" message for IRQ 0 means -- maybe it means Xen > won''t allow the IRQ to be shared with a guest? It seems to happen in a > loop that is initializing all the IRQs, not just the IRQ for the serial > port. > > > > Interestingly, I can make the hang go away by specifying > "acpi_skip_timer_override" to xen in grub.conf. AFAICT this is meant > for some BIOS issues, but I don''t think this system has a problem BIOS, > since it cleanly boots Xen 3.4.1 & CentOS 5.3 dom0 without > acpi_skip_timer_override. Does that sound like maybe some kind of > issue in the recent ACPI code? Would that be in Xen or in the dom0 > Linux? > > Well, to be fair, 5.3 is a bit ancient. And since then the ACPI code in > 2.6.31 handles much more - it might be that you are hitting something > new. > > I don''t remember, but did you try just booting bare-metal with the > pv-ops kernel? No Xen, just pv-ops by itself. Did it boot but without > the serial console? > > Also can you try booting the kernel with Xen, with ''initcall_debug'' for > your kernel command line? That "Xen: Cannot share IRQ0 with guest" is > troubling > me and I want to have an idea what part of the kernel code triggers > this.Everything seems to work if I specify acpi_skip_timer_override in grub.conf. I think I may be seeing the following issue: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/272247?comments=all System freezes during boot, unless I hold a key down Ubuntu >> "linux" package >> Bugs >> Bug #272247> The problem behind this seems not limited to a certain controller > chip, but related to ACPI BIOS definitions. The IRQ0 override > defines to which interrupt number the timer interrupt is supposed > to be routed. Most BIOS define a route to IRQ2, so the timer > source (hpet in most cases) has to deliver an IRQ2 whenever a > timer expires. The problem is, that this is not always correct > (either hpet does not use IRQ2 or IRQ2 is not enabled on the > chipset). So as soon as all CPUs go into sleep there is no > timer irq to wake them up. To solve this automatically one > would need documentation about the chipsets pci config space > which is often secret. > > Workaround for affected systems: Use of "acpi_skip_timer_override" > as kernel command line option. Sometimes "nohpet" or "acpi=noirq" > have been reported to work, too."Is there a way that I can verify that this is the issue? Thanks again, Ed _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2010-Mar-16 12:52 UTC
Re: [Xen-devel] dom0 hang in xen-4.0.0-rc5 - possible acpi issue? [WAS: Using xen-unstable, dom0 hangs during boot]
> > Everything seems to work if I specify acpi_skip_timer_override in grub.conf. I think I may be seeing the following issue: > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/272247?comments=all > System freezes during boot, unless I hold a key down > Ubuntu >> "linux" package >> Bugs >> Bug #272247 > > > The problem behind this seems not limited to a certain controller > > chip, but related to ACPI BIOS definitions. The IRQ0 override > > defines to which interrupt number the timer interrupt is supposed > > to be routed. Most BIOS define a route to IRQ2, so the timer > > source (hpet in most cases) has to deliver an IRQ2 whenever a > > timer expires. The problem is, that this is not always correct > > (either hpet does not use IRQ2 or IRQ2 is not enabled on the > > chipset). So as soon as all CPUs go into sleep there is no > > timer irq to wake them up. To solve this automatically one > > would need documentation about the chipsets pci config space > > which is often secret.Do you have the MCP67 chipset?> > > > Workaround for affected systems: Use of "acpi_skip_timer_override" > > as kernel command line option. Sometimes "nohpet" or "acpi=noirq" > > have been reported to work, too." > > > Is there a way that I can verify that this is the issue?Yes. You need to boot the pv-ops under bare-metal so that we can be sure this is not a Xen hypervisor problem, but the pv-ops kernel having an issue. Please provide the serial output with debugging turned on (debug initcall_debug apic=debug). Thanks. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nadolski, Ed
2010-Mar-17 16:34 UTC
RE: [Xen-devel] dom0 hang in xen-4.0.0-rc5 - possible acpi issue? [WAS: Using xen-unstable, dom0 hangs during boot]
> -----Original Message----- > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Tuesday, March 16, 2010 6:53 AM > To: Nadolski, Ed > Cc: Pasi Kärkkäinen; Jeremy Fitzhardinge; Xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] dom0 hang in xen-4.0.0-rc5 - possible acpi > issue? [WAS: Using xen-unstable, dom0 hangs during boot] > > > > > Everything seems to work if I specify acpi_skip_timer_override in > grub.conf. I think I may be seeing the following issue: > > > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/272247?comments=all > > System freezes during boot, unless I hold a key down > > Ubuntu >> "linux" package >> Bugs >> Bug #272247 > > > > > The problem behind this seems not limited to a certain controller > > > chip, but related to ACPI BIOS definitions. The IRQ0 override > > > defines to which interrupt number the timer interrupt is supposed > > > to be routed. Most BIOS define a route to IRQ2, so the timer > > > source (hpet in most cases) has to deliver an IRQ2 whenever a > > > timer expires. The problem is, that this is not always correct > > > (either hpet does not use IRQ2 or IRQ2 is not enabled on the > > > chipset). So as soon as all CPUs go into sleep there is no > > > timer irq to wake them up. To solve this automatically one > > > would need documentation about the chipsets pci config space > > > which is often secret. > > Do you have the MCP67 chipset?This is the Intel 5520 chipset (Dell T7500 quad-core Xeon workstation). (BTW I''m now running xen 4.0.0-rc6 and still seeing this.)> > > Workaround for affected systems: Use of "acpi_skip_timer_override" > > > as kernel command line option. Sometimes "nohpet" or "acpi=noirq" > > > have been reported to work, too." > > > > > > Is there a way that I can verify that this is the issue? > > Yes. You need to boot the pv-ops under bare-metal so that we can be sure > this is not a Xen hypervisor problem, but the pv-ops kernel having an issue.The pv-ops kernel boots fine on baremetal, without specifying acpi_skip_timer_override. So I guess this is a Xen issue after all. Here is the grub.conf that I used to boot the baremetal: title Fedora-12 (2.6.31.12) Baremetal dom0 boot root (hd0,0) kernel /vmlinuz-2.6.31.12 ro root=UUID=edbcbc29-f3e4-4985-80c1-3c3b0ce24d17 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=tty0 console=ttyS0,115200 debug initcall_debug apic=debug initrd /initramfs-2.6.31.12.img> Please provide the serial output with debugging turned on (debug > initcall_debug apic=debug).Attached. Thanks, Ed _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel