RE: [Xen-devel] dom0 hang in xen-4.0.0-rc5 - possible acpi issue? [WAS: Using xen-unstable, dom0 hangs during boot]

["Nadolski, Ed" <Ed.Nadolski@xxxxxxx>]

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx]
> Sent: Wednesday, March 03, 2010 11:19 AM
> To: Nadolski, Ed
> Cc: Pasi Kärkkäinen; Jeremy Fitzhardinge; Xen-devel@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel