[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Error getting mfn



On Sun, Sep 23, 2012 at 05:11:13PM +0200, William Dauchy wrote:
> On Thu, Sep 20, 2012 at 11:28 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx> wrote:
> > Ah. OK. so lets deal with one issue at hand. The CONFIG_NUMA - you said
> > you applied I posted for it some time ago? Is it this one?
> > http://lkml.indiana.edu/hypermail/linux/kernel/1205.3/03619.html
> 
> yes; and applied on my tests.
> 
> > For the non-NUMA case - can you try to compile a kernel without
> > NUMA enabled and also include 'earlyprintk=xen' on your Linux command
> > line? That should give me a good approximation of what/where
> > it is being hit.
> 
> Here is the log without NUMA enabled.

Initially I was thinking you might have:

commit 66a27dde9ae96e35278983f2e59bea04eb714cd0
Author: David Vrabel <david.vrabel@xxxxxxxxxx>
Date:   Mon Jul 9 11:39:06 2012 +0100

    xen/mm: zero PTEs for non-present MFNs in the initial page table
    
    When constructing the initial page tables, if the MFN for a usable PFN
    is missing in the p2m then that frame is initially ballooned out.  In
    this case, zero the PTE (as in decrease_reservation() in
    drivers/xen/balloon.c).
    
    This is obviously safe instead of having an valid PTE with an MFN of
    INVALID_P2M_ENTRY (~0).
    
    Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>

but that is the opposite problem - you would have bizzare PTEs like:

0xfffffffff023 which is not what you are seeing.

No, you are seeing us trying to allocate a PTE for which the M2P tells us
that we do not have. That either means somebody is trying to call
ioremap and we are using the PFN as if it was a MFN. Meaning PFN 2009b
is being set.. But I can't fanthom why it would - especially as you
are in the middle of the kernel mapping.

The other option is that our P2M has somewhere been corrupted? And
we decided to give you 2009b instead of something correct.

Can you give me access to your xen/kernel/initramfs images and
also your .config file. Maybe if I run it on my machine it
will shed some light.

> Reserving virtual address space above 0xfcc00000
> Linux version 3.4.11 (gcc version 4.4.5 (Debian 4.4.5-8) ) #18 SMP Sun
> Sep 23 14:32:16 UTC 2012
> KERNEL supported cpus:
>   Intel GenuineIntel
> Freeing  9b-100 pfn range: 101 pages freed
> 1-1 mapping on 9b->100
> 1-1 mapping on bf730->100000
> Released 101 pages of unused memory
> Set 264501 page(s) to 1-1 mapping
> BIOS-provided physical RAM map:
>  Xen: 0000000000000000 - 000000000009b000 (usable)
>  Xen: 000000000009b400 - 0000000000100000 (reserved)
>  Xen: 0000000000100000 - 0000000040065000 (usable)
>  Xen: 0000000040065000 - 00000000bf730000 (unusable)
>  Xen: 00000000bf730000 - 00000000bf73e000 (ACPI data)
>  Xen: 00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)
>  Xen: 00000000bf7a0000 - 00000000bf7b0000 (reserved)
>  Xen: 00000000bf7bc000 - 00000000c0000000 (reserved)
>  Xen: 00000000e0000000 - 00000000f0000000 (reserved)
>  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
>  Xen: 00000000fec8a000 - 00000000fec8b000 (reserved)
>  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
>  Xen: 00000000ffa00000 - 0000000100000000 (reserved)
>  Xen: 0000000100000000 - 0000000c40000000 (unusable)
> bootconsole [xenboot0] enabled
> NX (Execute Disable) protection: active
> DMI present.
> DMI: Dell       C6100           /0D61XP, BIOS 1.66 12/23/2011
> e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
> e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
> last_pfn = 0x40065 max_arch_pfn = 0x1000000
> initial memory mapped : 0 - 027ff000
> Base memory trampoline at [c009a000] 9a000 size 4096
> init_memory_mapping: 0000000000000000-00000000345fe000
>  0000000000 - 00345fe000 page 4k
> kernel direct mapping tables up to 345fe000 @ 2658000-27ff000
> (XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
> L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009b023
> (XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
> L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009c023
> (XEN) mm.c:908:d0 Error getting mfn 2009d (pfn 5555555555555555) from
> L1 entry 000000002009d023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009d023
> (XEN) mm.c:908:d0 Error getting mfn 2009e (pfn 5555555555555555) from
> L1 entry 000000002009e023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009e023
> (XEN) mm.c:908:d0 Error getting mfn 2009f (pfn 5555555555555555) from
> L1 entry 000000002009f023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009f023
> xen: setting RW the range 27e9000 - 27ff000
> RAMDISK: 017ce000 - 01ab2000
> ACPI: RSDP 000fa6f0 00024 (v02 ACPIAM)


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.