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

[Jeremy Fitzhardinge <jeremy@goop.org>]

 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