From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Bug#599089: linux-image-2.6.32-5-xen-686: Kernel Panics when using NFS from DomU to Dom0 Date: Tue, 05 Oct 2010 15:39:23 -0700 Message-ID: <4CABA91B.5020403@goop.org> References: <4CA9EF03.20407@gmail.com> <1286272060.23155.7508.camel@zakaz.uk.xensource.com> <1286272348.23155.7527.camel@zakaz.uk.xensource.com> <4CAB584A.7090909@goop.org> <1286302967.10974.1.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1286302967.10974.1.camel@localhost.localdomain> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: 599089@bugs.debian.org, xen-devel , Arnd Hannemann , Jason Kendall List-Id: xen-devel@lists.xenproject.org On 10/05/2010 11:22 AM, Ian Campbell wrote: > On Tue, 2010-10-05 at 09:54 -0700, Jeremy Fitzhardinge wrote: >> On 10/05/2010 02:52 AM, Ian Campbell wrote: >>> On Tue, 2010-10-05 at 10:47 +0100, Ian Campbell wrote: >>>> In addition to the kernel logging of the error I get this from the >>>> hypervisor: >>>> (XEN) mm.c:2062:d0 Error pfn 16d99: rd=ffff83011fefa000, >>>> od=0000000000000000, caf=180000000000000, taf=0000000000000000 >>>> (XEN) mm.c:658:d0 Could not get page ref for pfn 16d99 >>>> (XEN) mm.c:3621:d0 Could not get page for mach->phys update >>> Adding a bit more logging to the kernel I get: >>> gnttb_copy_grant_page old c22ebcd8 P:0x1ec8e M:0xc499d F:0x41000000 >>> gnttb_copy_grant_page new c2324ce0 P:0x1fe18 M:0x11cd32 F:0x40000000 >>> (XEN) mm.c:2062:d0 Error pfn 1cd32: rd=ffff83011fefa000, od=0000000000000000, caf=180000000000000, taf=0000000000000000 >>> (XEN) mm.c:658:d0 Could not get page ref for pfn 1cd32 >>> (XEN) mm.c:3621:d0 Could not get page for mach->phys update >>> >>> Notice how MFN 0x11cd32 has become 0x1cd32 by the time it gets to the >>> hypervisor! >> Oy, more of these. It might be better to use PFN_PHYS(). > I thought there ought to be a helper but couldn't find one, PFN_PHYS > sounds like a good bet, unless we want to alias it as MFN_MACH or > something? Doesn't really seem worth it, unless phys_addr_t ends up not being large enough for a machine address. But I think we rely on that pretty heavily anyway. I've committed it with that change. J