AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?

["Carsten Schiers" <carsten@xxxxxxxxxx>]

Forgot to attach the log, here it is:

BR,
Carsten.

-----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 2.6.32.18/21 
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 
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;
                WARN_ON_ONCE(is_ram);
        }

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.)

Jan

Attachment: putty.log
Description: Binary data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel