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


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

To: JBeulich <JBeulich@xxxxxxxxxx>
Subject: AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with pvops Kernel?
From: "Carsten Schiers" <carsten@xxxxxxxxxx>
Date: Wed, 8 Sep 2010 22:16:25 +0200
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 08 Sep 2010 13:18:21 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C87A2E60200007800014ED5@xxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Forgot to attach the log, here it is:


-----Ursprüngliche Nachricht-----
Von: Jan Beulich [mailto:JBeulich@xxxxxxxxxx] 
Gesendet: Mittwoch, 8. September 2010 14:51
An: Carsten Schiers
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Betreff: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 
pvops Kernel?

>>> On 08.09.10 at 14:15, Carsten Schiers <carsten@xxxxxxxxxx> wrote:
> (XEN) mm.c:860:d0 Error getting mfn 80000 (pfn 5555555555555555) from 
> 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) && 
                        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.)


Attachment: putty.log
Description: Binary data

Xen-devel mailing list