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: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] Xen dom0 crash: "d0:v0: unhandled page fault (ec=0000)"
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 01 Nov 2010 14:16:33 -0400
Cc: "Alan J. Wylie" <NDA5OWUy@xxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>, Stefan Kuhne <stefan.kuhne@xxxxxxx>, sven <ml@xxxxxxxxxxxxx>, Andreas Kinzler <ml-xen-devel@xxxxxx>
Delivery-date: Mon, 01 Nov 2010 11:17:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20101101174602.GA6227@xxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100921 Fedora/3.1.4-1.fc13 Lightning/1.0b3pre Thunderbird/3.1.4
 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?

    J


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