[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Dom0 hangs on boot, CentOS 5 x86_64


  • To: Steve Hill <steve@xxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 07 Nov 2007 10:28:48 +0000
  • Delivery-date: Wed, 07 Nov 2007 02:29:39 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcghKPtiOixPpI0cEdyy3wAX8io7RQ==
  • Thread-topic: [Xen-devel] Dom0 hangs on boot, CentOS 5 x86_64

If you can't boot 'acpi=off' with native Linux then that is not a good sign.
Your chances of booting on Xen without 'acpi=off' are small. When you
specify 'acpi=off' are you putting it on Xen's command line or dom0's? It
should be on Xen's -- if Xen and dom0 disagree about use of acpi then the
system is rather unlikely to boot.

If that's not the problem, but I suspect it is, then we need to look at what
output device you are using. Are you looking at VGA output or serial output?
If the latter then the ioapic write could be clobbering the serial irq.

 -- Keir

On 7/11/07 10:13, "Steve Hill" <steve@xxxxxxxxxxx> wrote:

> 
> I originally posted this to the xen-users list, but I think it might be
> more appropriate here since there is quite a lot of debugging:
> 
> I have been trying to get Xen working on an Intel S5000VLC motherboard in
> x86_64 mode running CentOS 5 (2.6.18 kernel).  It boots fine without Xen, but
> when running Xen I get a hang on boot while it is configuring the PCI devices.
> I've done some debugging, and it appears that the problem is a
> HYPERVISOR_physdev_op() call, which never returns.
> 
> 
> The call at fault is in io_apic_write() in arch/x86_64/kernel/io_apic-xen.c:
> HYPERVISOR_physdev_op(PHYSDEVOP_apic_write, &apic_op);
> which is called from io_apic_set_pci_routing() (in the same file):
> io_apic_write(ioapic, 0x10+2*pin, *(((int *)&entry)+0));
> called from mp_register_gsi() in arch/x86_64/kernel/mpparse-xen.c:
> io_apic_set_pci_routing(ioapic, ioapic_pin, gsi, triggering ==
> ACPI_EDGE_SENSITIVE ? 0 : 1, polarity == ACPI_ACTIVE_HIGH
> ? 0 : 1);
> called from acpi_register_gsi() in arch/i386/kernel/acpi/boot-xen.c:
> plat_gsi = mp_register_gsi(gsi, triggering, polarity);
> 
> I lost track of the calls at this point, but picked them up again in
> arch/i386/pci/common.c where pcibios_enable_device() calls:
> return pcibios_enable_irq(dev);
> which is called from pci_enable_device_bars() in drivers/pci/pci.c:
> err = pcibios_enable_device(dev, bars);
> called from pci_enable_device() in the same file:
> err = pci_enable_device_bars(dev, (1 << PCI_NUM_RESOURCES) - 1);
> called from drivers/pci/bus.c:
> retval = pci_enable_device(dev);
> 
> 
> The problem also happens under Fedora 7 when running Xen.
> 
> It looks like something might not be getting initialised, since the xen kernel
> boots fine if you boot the non-xen kernel first and then reboot without
> powering off in between.
> 
> The motherboard is running the latest (2 month old) BIOS, however I've noticed
> that the stock (non-Xen) Fedora 7 kernel fails to boot unless you specify
> acpi=off, so presumably the BIOS has some ACPI bugs.  Specifying acpi=off
> doesn't solve the Xen problem though.
> 
> I'd appreciate any suggestions.  I'm relatively happy poking around in the
> Linux kernel, but since it is a call to the Xen hypervisor which is hanging
> I'm 
> a bit stumped, having never looked at the Xen sourcecode before.
> 
> Thank you.



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.