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


[Xen-devel] Xen and crashdumps

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Xen and crashdumps
From: Goncalo Gomes <goncalo.gomes@xxxxxxxxxxxxx>
Date: Sun, 27 Dec 2009 23:13:24 +0000
Delivery-date: Sun, 27 Dec 2009 15:14:03 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Organization: Citrix Systems, Inc
Reply-to: Goncalo Gomes <Goncalo.Gomes@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (Windows/20090812)
I was wondering how do you usually analyze post-mortem dumps in atypical deployments of Xen with Linux as dom0 such as in Citrix XenServer, where the hypervisor is 64bit and the dom0 is 32bits (or the other way around - if architecturally possible - for that matter)?

If you have any thoughts on how to approach these scenarios, I would appreciate if you could shed some light. The crash utility and gdb doesn't seem to support these combinations out-of-the-box and the minidump output of the kdump tool in XenServer is only useful to find/understand the place in the text section where the softlockup is being triggered from, but not sufficient to understand why an IO region is faulting on access at some point during the driver execution when the driver itself only releases this region during cleanup (clearly not the case here, as it happens during intensive IO and the first few dozens of IOs actually go through). Analyzing the in memory kernel/xen/driver structures seems to be the next plausible step to further analyze/understand the issue that I can think of. Your thoughts on how to analyze the 64bit vmcore using a 32bit vmlinux are much appreciated, though.



Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Xen and crashdumps, Goncalo Gomes <=