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/
Home Products Support Community News


Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with pvops Kernel

To: "Carsten Schiers" <carsten@xxxxxxxxxx>
Subject: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with pvops Kernel?
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Wed, 08 Sep 2010 13:51:18 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 08 Sep 2010 05:52:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <8938594.271283948103002.JavaMail.root@uhura>
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: <8938594.271283948103002.JavaMail.root@uhura>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 08.09.10 at 14:15, Carsten Schiers <carsten@xxxxxxxxxx> wrote:
> (XEN) mm.c:860:d0 Error getting mfn 80000 (pfn 5555555555555555) from L1 
> entry 8000000080000473 for l1e_owner=0, pg_owner=32753

DOMID_IO seen here generally means that Dom0 tried to map a page
it doesn't own (likely because of your use of dom0_mem=). As the
page really is a RAM one, Xen doesn't allow the access. Given that
this apparently happens in the context of
acpi_ex_system_memory_space_handler() you'd have to look at (or
provide) your DSDT and SSDT(s) to see where this reference comes
from. Very likely this is just a bogus reference, that you get away
with on native, perhaps because this code in ioremap.c

        last_pfn = last_addr >> PAGE_SHIFT;
        for (pfn = phys_addr >> PAGE_SHIFT; pfn <= last_pfn; pfn++) {
                int is_ram = page_is_ram(pfn);

                if (is_ram && pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn)))
                        return NULL;

should result in returning NULL there, while it wouldn't cover the
situation under Xen. (While the code is meaningless under Xen in
its current shape anyway, using dom0_mem= with a value above
2G should get you around the issue, as then PFN 0x80000 would
be considered RAM there too.)


Xen-devel mailing list