From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick Colp Subject: Re: Xen cannot boot with pvops dom0 Date: Wed, 1 Jul 2009 08:32:18 +0100 Message-ID: <4A4B1102.6090401@citrix.com> References: <715D42877B251141A38726ABF5CABF2C0545A1F383@pdsmsx503.ccr.corp.intel.com> <4A434550.7070500@citrix.com> <4A4A2B68.7050700@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4A4A2B68.7050700@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: "xen-devel@lists.xensource.com" , "Han, Weidong" , Jun Koi List-Id: xen-devel@lists.xenproject.org Hmmm, OK. Well, something is still going wrong. I find that adding things like irqpoll and/or acpi=noirq seems to help a bit. By that I mean that it gets further into the boot process before stalling. If I wait a while and press random keys/buttons (like Num Lock or the power button), then that seems to coax it into booting a little bit more, but I've never managed to get it to completely boot. The furthest I got was to where it tries to read the root filesystem. I could give you a dump of the boot-up messages, but aside from the ioapic stuff, there's nothing out of the ordinary. Patrick Jeremy Fitzhardinge wrote: > On 06/25/09 02:37, Patrick Colp wrote: >> I don't think this is an issue with out the kernel was compiled. In >> fact, all of the ways mentioned will build the pvops kernel properly. >> I have run into a similar problem with the kernel trying to >> add/remove/modify ioapic stuff as well (and have tried to compile the >> kernel in every possible way, but still get the same problem). >> >> I have a feeling it is an issue with the pvops kernel ioapic code and >> have spent some time trying to track it down, but haven't found >> anything yet. > > Those messages are just noise, and are harmless. They're the kernel's > core drivers trying to take over various pieces of important hardware > that Xen already owns. So far it has just been easier to let the kernel > try and fail to take over the interrupts than to try to suppress the > messages. > > J