[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110131112108.GA30595@router-fw-old.local.net-space.pl>
Date: Mon, 31 Jan 2011 12:21:08 +0100
From: Daniel Kiper <dkiper@...-space.pl>
To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc: Daniel Kiper <dkiper@...-space.pl>, linux-kernel@...r.kernel.org,
stable@...nel.org, x86@...nel.org, xen-devel@...ts.xensource.com,
jeremy@...p.org, mingo@...hat.com, mingo@...e.hu,
stefan.bader@...onical.com
Subject: Re: [Xen-devel] [PATCH] xen: convert p2m to a 3 level tree - partial revert
Hi,
On Thu, Jan 27, 2011 at 10:25:08AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 27, 2011 at 03:48:43PM +0100, Daniel Kiper wrote:
> > Hi,
> >
> > Durning work on Xen memory hotplug I discoverd that
> > 2.6.38-rc2 does not boot on domU. After some investigation
> > it appeared that 58e05027b530ff081ecea68e38de8d59db8f87e0
> > commit changed CONFIG_XEN_MAX_DOMAIN_MEMORY constant value
> > to 128. This change does not allow to boot kernel on domU
> > with small memory size (I could confirm that it is even
> > not possible to boot kernel on domU with 2 GiB). Guest
>
> Strange.. I've been booting with 1G, 2G, 3G, 4G guests.
>
> Could you give more details? Is this a 32-bit guest? 64-bit?
> What does your xm file look like?
>
> > crash silently without any warning. Durning further
> > research I found out that there is another commit published
> > recently (8e1b4cf2108488ccfb9a3e7ed7cd85a435e01d4b) which attempts
> > to fix this issue, however, it does not work on my platform.
> > I decided to reenable CONFIG_XEN_MAX_DOMAIN_MEMORY option in
> > kernel config and enable users to choose resonable values for
> > their machines until better fix will be published. I think this
> > solution is good because allow users to boot domU with newest
> > kernel and allow developers to continue their work without
> > time presure which could lead to new bugs.
>
> I think you are hitting a completly different bug. This
> patch of yours changes the size of the structure - so it could
> be that you are hitting a page-table overwrite. This is something
> that Stefano has been looking at - you might want to take a look at
> "x86: When destroying mappings between _brk_end and _end, do not go over _end"
> (it is present in his git tree).
It appears that this patch fixed issue described above. In this
situation I think it should be applied ASAP to RC and stable kernels.
Thank you for your help.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists