WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Debian Lenny 2.6.26-2-xen-686 crashing as multi-vcpu dom

To: "Pasi Kärkkäinen" <pasik@xxxxxx>
Subject: Re: [Xen-devel] Debian Lenny 2.6.26-2-xen-686 crashing as multi-vcpu domU, stack trace
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Mon, 08 Mar 2010 08:54:49 +0000
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 08 Mar 2010 00:55:48 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100308083648.GS2580@xxxxxxxxxxx>
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: <20100305124709.GA2580@xxxxxxxxxxx> <4B910E870200007800032F92@xxxxxxxxxxxxxxxxxx> <20100307155253.GP2580@xxxxxxxxxxx> <4B94BDD80200007800033307@xxxxxxxxxxxxxxxxxx> <20100308083648.GS2580@xxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Pasi Kärkkäinen<pasik@xxxxxx> 08.03.10 09:36 >>>
>I still have the guest up.. in the crashed state. 
>Anything that I should try? 

It's not really something you should try, it's really the analysis of the
call stack that's going to get you forward. In particular, after
reconstructing the true call stack (i.e. with all false entries removed)
and after determining which two locks are being acquired by the two
vCPU-s, it should be possible to determine whether respectively the
other vCPU is currently holding those locks.

Plus this work would also show whether the handle_bad_irq()
entries on the stack are directly or only indirectly (and hence only
possibly) related to the issue.

Jan



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