From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Xen-unstable panic: FATAL PAGE FAULT Date: Wed, 01 Sep 2010 10:01:57 +0100 Message-ID: <4C7E32A50200007800013A3F@vpn.id2.novell.com> References: <4C7E24BE02000078000139EC@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , MaoXiaoyun Cc: xen devel List-Id: xen-devel@lists.xenproject.org >>> On 01.09.10 at 10:49, Keir Fraser wrote: > Okay, my next guess then is that we are deleting a chunk from the wrong = list > head. I don't see any check that the adjacent chunks we are considering = to > merge are from the same node and zone. I suppose the zone logic does = just > work as we're dealing with 2**x aligned and sized regions. But, = shouldn't > the merging logic in free_heap_pages be checking that the merging = candidate > is from the same NUMA node? I see I have an ASSERTion later in the same > function, but it's too weak and wishful I suspect. Hmm, we're keeping a page reserved if node boundaries aren't well aligned (at the end of init_heap_pages()), so that shouldn't be possible. MaoXiaoyun: Would it be possible that we get to see a *full* boot log (at maximum log level), so we know the characteristics of the machine? Jan