WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen dom0 crash: "d0:v0: unhandled page fault (ec=0000)"

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Xen dom0 crash: "d0:v0: unhandled page fault (ec=0000)"
From: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
Date: Mon, 1 Nov 2010 18:19:17 +0000
Cc: "Alan J. Wylie" <NDA5OWUy@xxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Stefan Kuhne <stefan.kuhne@xxxxxxx>, sven <ml@xxxxxxxxxxxxx>, Andreas Kinzler <ml-xen-devel@xxxxxx>
Delivery-date: Mon, 01 Nov 2010 11:20:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CCF0401.5040704@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <19629.39326.337589.71778@xxxxxxxxxxx> <1287498599.12843.2111.camel@xxxxxxxxxxxxxxxxxxxxxx> <4CBDB229.3030501@xxxxxxxxxxxxx> <1287503143.12843.2191.camel@xxxxxxxxxxxxxxxxxxxxxx> <4CBE2A43.70200@xxxxxx> <1287564863.12843.4194.camel@xxxxxxxxxxxxxxxxxxxxxx> <1288367063.23619.51.camel@xxxxxxxxxxxxxxxxxxxxxx> <20101029161553.GA27408@xxxxxxxxxxxx> <4CCEC2A8.6040103@xxxxxxxx> <20101101173940.GA6068@xxxxxxxxxxxx> <20101101174602.GA6227@xxxxxxxxxxxx> <4CCF0401.5040704@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2010-11-01 at 18:16 +0000, Jeremy Fitzhardinge wrote:
> On 11/01/2010 01:46 PM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 01, 2010 at 01:39:40PM -0400, Konrad Rzeszutek Wilk wrote:
> >>>>> http://pastebin.com/3m0DpDdW - 2.6.32.24-gd0054d6-dirty - broken
> >> .. snip..
> >>> The way is this is supposed to work is:
> >>>
> >>>    1. Xen gives the domain N pages
> >>>    2. There's an E820 which describes M pages (M > N)
> >>>    3. The kernel traverses the existing E820 and finds holes and adds
> >>>       the memory to a new E820_RAM region beyond M
> >>>    4. Set up P2M for pages up to N
> >>>    5. When the kernel maps all "RAM", the region from N-M is not
> >>>       present, and has no valid P2M mapping; in that case, xen_make_pte
> >>>       will return a non-present pte.
> >> Right, and somehow his machine/kernel is not doing this. His 'N' ends up 
> >> being 'M' so
> >> the region N-M is added to the "RAM", and xen_make_pte I _think_ returns a 
> >> non-present pte
> >> (or maybe it does present a present pte?) In the previous kernel 
> >> (2.6.32.18), it
> >> does exactly what you described.
> > Not that I am actually sure what is causing this. The interesting part is 
> > that
> > he sees this twice:
> >
> > [    0.000000] last_pfn = 0x2d0699 max_arch_pfn = 0x400000000
> > [    0.000000] last_pfn = 0x2f000 max_arch_pfn = 0x400000000
> >
> > And he mentioned on IRC to me that this was not due to any debugging 
> > patches.
> 
> That's just printed by e820_end_pfn(), which is called a few times. 
> Does it happen native?

It's just called twice once for max mem and once for max_low_mem which
are different for me (ie. correspond to N and M respectively).

Not sure if it happens on bare metal

Gianni


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel