From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel? Date: Wed, 08 Sep 2010 13:51:18 +0100 Message-ID: <4C87A2E60200007800014ED5@vpn.id2.novell.com> References: <8938594.271283948103002.JavaMail.root@uhura> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <8938594.271283948103002.JavaMail.root@uhura> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Carsten Schiers Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> On 08.09.10 at 14:15, Carsten Schiers wrote: > (XEN) mm.c:860:d0 Error getting mfn 80000 (pfn 5555555555555555) from = L1=20 > entry 8000000080000473 for l1e_owner=3D0, pg_owner=3D32753 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=3D). 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 =3D last_addr >> PAGE_SHIFT; for (pfn =3D phys_addr >> PAGE_SHIFT; pfn <=3D last_pfn; pfn++) { int is_ram =3D page_is_ram(pfn); if (is_ram && pfn_valid(pfn) && !PageReserved(pfn_to_page(p= fn))) 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=3D with a value above 2G should get you around the issue, as then PFN 0x80000 would be considered RAM there too.) Jan