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] kernel BUG at arch/x86/xen/mmu.c:1860!

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] kernel BUG at arch/x86/xen/mmu.c:1860!
From: Christophe Saout <christophe@xxxxxxxx>
Date: Tue, 04 Jan 2011 19:40:10 +0100
Cc: Teck Choon Giam <giamteckchoon@xxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Tue, 04 Jan 2011 10:41:35 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=saout.de; s=default; t=1294166388; bh=B6yrgSSXnO1fX4u1wyTVYzrjy9kL/LvSNd8y92MJYOo=; h=Subject:From:In-Reply-To:References:Date:Message-ID; b=QYXG1aYRdjGz0ZG5nkC5B4oIvTHpLmW2SxK90sbQYXo8rv2O7AB3L1H+0pj4MZK0K 7f394zU52FKecxOJnPkg88aYgB5KV4S0CQKxWbjSDbBGavYC0SRVts0CZ98VI7IiN2 ubzKnAeAq9ZrpCltTjX9ZIA0J448K6Il0Bnae4yw=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1294154342.24719.6.camel@xxxxxxxxxxxxxxxxxxxx>
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: <AANLkTi=Hwjooo43FiLPAAGzzOTG440ij_QsEqks6ECVv@xxxxxxxxxxxxxx> <20101227155314.GG3728@xxxxxxxxxxxx> <AANLkTikNvKGc78HQOMtVfi=Q+r8r92=svzZcMLQ2xojQ@xxxxxxxxxxxxxx> <20101228104256.GJ2754@xxxxxxxxxxx> <1294153817.24719.3.camel@xxxxxxxxxxxxxxxxxxxx> <1294154342.24719.6.camel@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi once more,

> > It doesn't look like this has been resolved yet.  Somewhere I saw a
> > request for the hypervisor message related to the pinning failure.
> > 
> > Here it is:
> > 
> > (XEN) mm.c:2364:d0 Bad type (saw 7400000000000001 != exp 1000000000000000) 
> > for mfn 41114f (pfn d514f)
> > (XEN) mm.c:2733:d0 Error while pinning mfn 41114f
> > 
> > I have a bit of experience in debugging things, so if I can help someone
> > with more information...
>  [<ffffffff810052e2>] pin_pagetable_pfn+0x52/0x60    
>  [<ffffffff81006f5c>] xen_alloc_ptpage+0x9c/0xa0
>  [<ffffffff81006f8e>] xen_alloc_pte+0xe/0x10
>  [<ffffffff810decde>] __pte_alloc+0x7e/0xf0
>  [<ffffffff810e15c5>] handle_mm_fault+0x855/0x930
>  [<ffffffff8102dd9e>] ? pvclock_clocksource_read+0x4e/0x100
>  [<ffffffff810e734c>] ? do_mmap_pgoff+0x33c/0x380
>  [<ffffffff81452b96>] do_page_fault+0x116/0x3e0
>  [<ffffffff8144ff65>] page_fault+0x25/0x30

> Additional information: This happened with a number of commands now.
> However, I am running a multipath setup and every time the crash
> seemed to be caused in the process context of the multipath daemon. 
> I think the daemon listens to events from the device-mapper subsystem
> to watch for changes and the problem somehow arises from there, since
> on another machine with the same XEN/Dom0 version without such a
> daemon I never had any troubles with LVM.

On further investigation is seems that most of the time the issue is not
caused by the daemon, but by the "multipath" tool, which is used a lot
by udev to identify properties of block devices.

When I start stracing udevd (following forks), I'm not able to reproduce
the crash anymore.  So I was hoping to find out what the process was
doing before the crash occurs, but since my attempts to trace the
process masks the bug, I can't. :(

(without strace, the bug is very common, about every third "lvcreate"
command.  Every lvcreate command triggers about 20 multipath


Xen-devel mailing list