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