----- Original Message ----- > Hi, > > > crash 5.1.9 > > Copyright (C) 2002-2011 Red Hat, Inc. > > Copyright (C) 2004, 2005, 2006 IBM Corporation > > Copyright (C) 1999-2006 Hewlett-Packard Co > > Copyright (C) 2005, 2006 Fujitsu Limited > > Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. > > Copyright (C) 2005 NEC Corporation > > Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. > > Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. > > This program is free software, covered by the GNU General Public > > License, > > and you are welcome to change it and/or distribute copies of it > > under > > certain conditions. Enter "help copying" to see the conditions. > > This program has absolutely no warranty. Enter "help warranty" for > > details. > > > > crash: vmlinux-3.0.13-0.27-xen.gz: original filename unknown > > Use "-f vmlinux-3.0.13-0.27-xen.gz" on command line to prevent this > > message. > > > > GNU gdb (GDB) 7.0 > > Copyright (C) 2009 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > <http://gnu.org/licenses/gpl.html> > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. Type "show > > copying" > > and "show warranty" for details. > > This GDB was configured as "x86_64-unknown-linux-gnu"... > > > > KERNEL: vmlinux-3.0.13-0.27-xen.gz > > DEBUGINFO: ../lib/debug/boot/vmlinux-3.0.13-0.27-xen.debug > > DUMPFILE: /mnt/winimg/crash/2012-09-30-19:03/vmcore > > CPUS: 2 > > DATE: Sun Sep 30 19:02:52 2012 > > UPTIME: 07:45:24 > > LOAD AVERAGE: 0.32, 0.23, 0.14 > > TASKS: 207 > > NODENAME: HjCloud > > RELEASE: 3.0.13-0.27-xen > > VERSION: #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) > > MACHINE: x86_64 (2793 Mhz) > > MEMORY: 3.6 GB > > PANIC: "[27924.896523] Oops: 0002 [#1] SMP " (check log for > > details) > > PID: 7450 > > COMMAND: "bash" > > TASK: ffff8800cfbf61c0 [THREAD_INFO: ffff8800cba86000] > > CPU: 1 > > STATE: TASK_RUNNING (PANIC) > > [...] > > It looks that crash tool reads only dom0 part. > However, it looks that there is also some info > about Xen hypervisor state, too. I heard that > it is possible to do that in that way but personally > I did not such things. I think that you should > first check SLES documentation (man crash?)/groups/... > As I know this distribution use strongly customized > things (e.g. Linux Kernel) and they could behave > differently then vanilla one. > > I am going to check that once but > now I am working on other things. > > Daniel That has always been the case -- at least up until the most recent version of Xen (3.1-era) that Red Hat supported -- where a kdump vmcore that is taken on the dom0 host can be analyzed either from the viewpoint of the dom0 vmlinux kernel or from the viewpoint of the xen-syms hypervisor. And for that matter, given that it's a dump of all physical memory, you can also analyze any of the guest vmlinux kernels if you know what the value of the pfn_to_mfn_list_list pfn is: $ crash -h ... --p2m_mfn pfn When a Xen Hypervisor or its dom0 kernel crashes, the dumpfile is typically analyzed with either the Xen hypervisor or the dom0 kernel. It is also possible to analyze any of the guest domU kernels if the pfn_to_mfn_list_list pfn value of the guest kernel is passed on the command line along with its NAMELIST and the dumpfile. So anyway, Hu shows that the vmlinux/vmcore pair works OK, but the xen-syms/vmcore pair is not working with his more recent version of Xen (4.1.3). I would have thought that your recent patch set would have addressed his Xen version? On the other hand, I cannot confirm whether SLES does something differently such that their Xen hypervisor is patched to such a degree that it doesn't work with crash-6.1.0? Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility