<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=us-ascii"> <META content="MSHTML 6.00.2800.1528" name=GENERATOR></HEAD> <BODY> <DIV dir=ltr align=left>Dave Anderson wrote: </DIV> <BLOCKQUOTE TYPE="CITE">"Sampathkumar, Kishore (STSD)" wrote: <BLOCKQUOTE TYPE="CITE">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 <PRE WRAP><HR width="90%" SIZE=4>-- Crash-utility mailing list Crash-utility@redhat.com <A href="https://www.redhat.com/mailman/listinfo/crash-utility">https://www.redhat.com/mailman/listinfo/crash-utility</A></PRE></BLOCKQUOTE> <TT>Hi Sampathkumar,</TT> <TT>First thing, presuming that the vmlinux file is associated with the vmcore</TT> <TT>file, take the System-map argument out of the picture -- i.e, invoke the</TT> <TT>session as:</TT> <TT> $ crash -d7 vmlinux vmcore</TT> <TT>the -d7 will display a bunch of debug data.</TT> <TT>What looks unusual is the ffffffff813a8200 address for "xtime". That</TT> <TT>would seem to be too high -- except perhaps if the vmlinux you're working</TT> <TT>against (or maybe the unnecessary System-map) is the kdump kernel loaded</TT> <TT>at 16MB?</TT> <TT>If you do this, the output should show the exact same kernels:</TT> <TT> $ strings vmcore | grep "Linux version"</TT> <TT> $ strings vmlinux | grep "Linux version"</TT> <TT>Dave</TT> </BLOCKQUOTE><TT>Hi Kishore,</TT><TT></TT> <TT>On a RHEL4 x86_64 kernel, "xtime" is typically an address about</TT> <TT>3-4 MB from the beginning load address of the kernel, (i.e. add</TT> <TT>about 3-4 MB to the base virtual address of ffffffff80000000),</TT> <TT>whereas your example shows it at about 19MB (13a8200). Given that</TT> <TT>the dumpfile read of ffffffff813a8200 failed, it looks as if the</TT> <TT>physical memory region containing that address was not dumped,</TT> <TT>which AFAICT with other kdump dumpfiles I have on-hand, the</TT> <TT>"64MB@16MB" (or whatever size at 16MB) that is reserved for</TT> <TT>the kdump kernel would *not* be captured in the /proc/vmcore</TT> <TT>file. So that kind of reinforces my suggestion that you are</TT> <TT>perhaps using the wrong vmlinux (or System-map) associated with</TT> <TT>the vmcore file.</TT><TT></TT> <TT>Dave</TT> <HR tabIndex=-1> 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</BODY></HTML>