From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Re: [Xen-users] Hypervisor hangs on startup, 2.6.32-5-xen dom0 kernel panic Date: Tue, 11 Jan 2011 11:38:28 -0500 Message-ID: <20110111163828.GF10897@dumpdata.com> References: <4D0AD782.8030204@wavecon.de> <4D0B3DF2.5000100@wavecon.de> <20101217115132.GG2754@reaktio.net> <4D0B7E79.4010106@wavecon.de> <20101220201819.GN2754@reaktio.net> <1292937209.4500.1852.camel@zakaz.uk.xensource.com> <4D2496DE.1000007@wavecon.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4D2496DE.1000007@wavecon.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Arno Toell Cc: "xen-devel@lists.xensource.com" , Ian Campbell , "xen-users@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Wed, Jan 05, 2011 at 05:05:50PM +0100, Arno Toell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > This suggests that the xen_exchange_memory hypercall has failed for some > > reason. > > > > -12 is -ENOMEM but size is only 64M and this is start of day so I can't > > think why this would be the case (or at least why it wouldn't always be > > the case if it was happening at all). > > I was speaking earlier today to Pasi about this bug again by accident. > There he asked whether I did try to boot the xen-4.0-testing tree. Now I > did, as I built the most recent -testing snapshot and I have some more > to add: > > Booting the Xen hypervisor in version 4.0.2-rc1-pre built by myself on > the affected system resulted in no failure for Debian's stock > 2.6.32-5-xen-amd64 kernel. Jeremy's xen tree at > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git (resulting > in 2.6.32.27) failed to boot, but that is my fault as I was too lazy to > build an appropriate .config. So this is NOT related to the bug. > > So the question is now, whether there was a bug in 4.0.1 that has been > fixed in -testing which fixes this one as well (or if it is a duplicate There was some fix for the VT-d allocation that ended up crashing Dom0 (b/c of an memory accounting issue). It could have been that was what you hit. I don't remember the changeset number, but you could try booting your old hypervisor without the Vt-D and see if that was it (iommu=off) ?