Re: Xen-unstable panic: FATAL PAGE FAULT

[Keir Fraser <keir.fraser@eu.citrix.com>]

On 01/09/2010 08:17, "MaoXiaoyun" <tinnycloud@hotmail.com> wrote:

> As I go through the chunk merge code in free_heap_pages, one thing I'd like
> to mention is, previously, I printted out all domain pages when allocated,
> and I found the order in assgin_pages in
> /xen-4.0.0/xen/common/page_alloc.c:1087,
> the order either be 0, or 9, and later I know that is because domain U
> populate physmap
> 2M Bytes everytime.
>  
> And here in the while statement,  the order is compare with MAX_ORDER, which
> is 20.
> I wonder if it might have some clues.

Xen's buddy allocator merges pairs of adjacent free chunks up to a maximum
size of 2**20 pages. That merging needs to be careful it doesn't merge off
the end of RAM. I'm just guessing that maybe there's an issue with that on
your fairly large memory system.

 -- Keir

> Thanks.
> -------------------------------
>  531 
>  532     /* Merge chunks as far as possible. */
>  533     while ( order < MAX_ORDER )
>  534     {
>  535         mask = 1UL << order;
>  
>> Date: Tue, 31 Aug 2010 18:03:41 +0100
>> Subject: Re: [Xen-devel] Xen-unstable panic: FATAL PAGE FAULT
>> From: keir.fraser@eu.citrix.com
>> To: JBeulich@novell.com
>> CC: tinnycloud@hotmail.com; xen-devel@lists.xensource.com
>> 
>> On 31/08/2010 17:35, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:
>> 
>>>> 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.
>>> 
>>> 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?
>> 
>> 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.
>> 
>> I think an obvious next step wpuld be to get your boot output, MaoXiaoyun.
>> Can you please post it? And you may as well stop your memtest if you haven't
>> already. If you've seen the issue on more than one machine then it certainly
>> isn't due to that kind of hardware failure.
>> 
>> -- Keir
>> 
>> 
>