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 09:02:38 +0100 Message-ID: <4C7E24BE02000078000139EC@vpn.id2.novell.com> References: 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 Cc: MaoXiaoyun , xen devel List-Id: xen-devel@lists.xenproject.org >>> On 31.08.10 at 19:03, Keir Fraser wrote: > On 31/08/2010 17:35, "Keir Fraser" wrote: >=20 >>> That's somewhat implicit: srat_parse_regions() gets passed an >>> address that is at least BOOTSTRAP_DIRECTMAP_END (i.e. 4G). >>> Thus srat_parse_regions() starts off with a mask with the lower >>> 32 bits all set (only more bits can get set subsequently). Thus >>> the earliest zero bit pfn_pdx_hole_setup() can find is bit 20 >>> (due to the >> PAGE_SHIFT in the invocation). Consequently >>> the smallest chunk where arithmetic is valid really is 4Gb, not >>> 256Mb as I first wrote. >>=20 >> Well, that's a bit too implicit for me. How about we initialise 'j' to >> MAX_ORDER in pfn_pdx_hole_setup() with a comment about supporting = page_info >> pointer arithmetic within allocatable multi-page regions? >=20 > Well I agree with your logic anyway. So I don't see that this can be the > cause of MaoXiaoyun's bug. At least not directly. But then I'm stumped = as to > why the page arithmetic and checks in free_heap_pages are (apparently) > resulting in a page pointer way outside the frame-table region and = actually > in the directmap region. There must be some unchecked use of PAGE_LIST_NULL, i.e. running off a list end without taking notice (0xffff8315ffffffe4 exactly corresponds with that). Jan