Dave Anderson wrote:
"Sampathkumar, Kishore (STSD)" wrote:
Hi,I have been working on back-porting kexec/kdump
functionality from 2.6.13 vanilla kernel to RHEL4, Update 2 kernel
(version 2.6.9-22).As part of that, when I try to invoke "crash" on a
vmcore generated, I get the following error in "crash" tool:[root
crash-4.0-2.23]# ./crash /boot/System.map-2.6.9-kdump-1
/usr/src/redhat/BUILD/kernel-2.6.9-kdump-1/linux- 2.6.9/vmlinux
/root/vmcorecrash 4.0-2.23
Copyright (C) 2002, 2003, 2004, 2005, 2006 Red Hat,
Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005 Fujitsu Limited
Copyright (C) 2005 NEC Corporation
Copyright (C) 1999, 2002 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.GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB 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.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show
warranty" for details.
This GDB was configured as
"x86_64-unknown-linux-gnu"...crash: read error: kernel virtual address:
ffffffff813a8200 type: "xtime"[root crash-4.0-2.23]# [root
crash-4.0-2.23]# I tried with both crash-4.0-2.15 as well as
crash-4.0-2.23. Same result.- Should I be re-building crash as part of
the back-port?- Is crash capable of handing vmcore's generated by
kdump?- Can someone suggest how I can make progress to get crash to work
for this?Thanks,- Kishore
________________________________
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Hi Sampathkumar,
First thing, presuming that the vmlinux file is associated with
the vmcore
file, take the System-map argument out of the picture -- i.e,
invoke the
session as:
$ crash -d7 vmlinux vmcore
the -d7 will display a bunch of debug data.
What looks unusual is the ffffffff813a8200 address for "xtime".
That
would seem to be too high -- except perhaps if the vmlinux
you're working
against (or maybe the unnecessary System-map) is the kdump
kernel loaded
at 16MB?
If you do this, the output should show the exact same kernels:
$ strings vmcore | grep "Linux version"
$ strings vmlinux | grep "Linux version"
Dave
Hi Kishore,
On a RHEL4 x86_64 kernel, "xtime" is typically an address about
3-4 MB from the beginning load address of the kernel, (i.e. add
about 3-4 MB to the base virtual address of ffffffff80000000),
whereas your example shows it at about 19MB (13a8200). Given that
the dumpfile read of ffffffff813a8200 failed, it looks as if the
physical memory region containing that address was not dumped,
which AFAICT with other kdump dumpfiles I have on-hand, the
"64MB@16MB" (or whatever size at 16MB) that is reserved for
the kdump kernel would *not* be captured in the /proc/vmcore
file. So that kind of reinforces my suggestion that you are
perhaps using the wrong vmlinux (or System-map) associated with
the vmcore file.
Dave
________________________________
Hello Dave,
You are right on dot!
After obtaining the vmcore using kdump, I was supplying the second
kernel (i.e., "capture" kernel as per kexec/kdump terminology) and its
System-map file to "crash" tool, while the vmcore corresponds to the
"panic'ing" kernel (i.e., "first" kernel as per kexec/kdump
terminology).
Doing a "strings" on both the vmcore and vmlinux, as you suggested,
immediately pointed out the blunder I was committing.
I tried invoking crash tool using the vmcore and the corresponding
kernel (i.e., the first --panic'ing-- kernel): it works fine, both with
crash-4.0-2.15 as well as crash-4.0-2.23.
Thanks!
Regards,
- Kishore