lkml.org 
[lkml]   [2004]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH][1/6]Documentation
Regards, Hari
--
Hariprasad Nellitheertha
Linux Technology Center
India Software Labs
IBM India, Bangalore


This patch contains the documentation for the kexec based crash dump tool.

Signed off by Hariprasad Nellitheertha <hari@in.ibm.com>



---

linux-2.6.8.1-hari/Documentation/kdump.txt | 101 +++++++++++++++++++++++++++++
1 files changed, 101 insertions(+)

diff -puN /dev/null Documentation/kdump.txt
--- /dev/null 2003-01-30 15:54:37.000000000 +0530
+++ linux-2.6.8.1-hari/Documentation/kdump.txt 2004-08-17 17:03:19.000000000 +0530
@@ -0,0 +1,101 @@
+Documentation for kdump - the kexec based crash dumping solution
+================================================================
+
+DESIGN
+======
+
+We use kexec to reboot to a second kernel whenever a dump needs to be taken.
+This second kernel is booted with with very little memory (current
+implementation has this at 16MB). The contents of the 16MB of memory that
+the second kernel uses is copied onto a reserved area, before rebooting. So,
+we have the entire memory image of the previous kernel preserved.
+
+In the second kernel, this "old memory" can be accessed in two ways. The
+first one is through a device interface. We can create a /dev/hmem or
+whatever and write out the memory in raw format. The second interface is
+through /proc/vmcore. This exports the dump as an ELF format file which
+can be written out using any file copy command (cp, scp, etc). Further, gdb
+can be used to perform some minimal debugging on the dump file.
+
+Note that the two approaches are independent and the patches
+can be used depending on the functionality needed. More details on the
+patches below.
+
+PATCHES
+=======
+
+We currently have 6 patches.
+
+1) kd-doc-<version>.patch - Contains basic documentation (this document!!)
+2) kd-reb-<version>.patch - This patch ensures we do a kexec reboot upon panic
+ and also saves the first 16MB of memory into a backup area
+3) kd-copy-<version>.patch - This contains the code for reading the dump pages
+ in the second kernel.
+4) kd-reg-<version>.patch - This patch is for snapshotting the register contents
+ of all processors on to the backup area before rebooting.
+5) kd-elf-<version>.patch - This patch provides an ELF format interface to
+ the dump, post-reboot.
+6) kd-hmem-<version>.patch - This patch contains the code to access the dump as
+ an /dev/hmem.
+
+SETUP
+=====
+
+1) Apply the kexec patch on to the appropriate vanilla kernel tree.
+ The latest version of the kexec patch can be obtained from
+ http://www.xmission.com/~ebiederm/files/kexec/2.6.8-rc1-kexec1/
+ This patch should apply on 2.6.8-rc4 as well.
+ Older kexec patches can be found at
+ http://developer.osdl.org/rddunlap/kexec/
+
+2) Apply the crash dump patches.
+
+3) Ensure you have chosen the "kernel crash dumps" option under "Processor
+ type and features" and also the kexec syscall option under kernel hacking
+
+4) Load the second kernel to be booted using
+
+ kexec -l <kernel> --append="root=<root-dev> mem=16M dump init 1"
+
+5) System reboots into the second kernel when a panic occurs.
+ You could write a module to call panic, for testing purposes.
+
+6) Write out the dump file using
+
+ cp /proc/vmcore <dump-file>
+
+You can also access the dump as a device for a linear/raw view. To do this,
+you will need the kd-hmem-<version>.patch built into the kernel. To create
+the device, type
+
+ mknod /dev/hmem c 1 12
+
+Use "dd" with suitable options for count, bs and skip to access specific
+portions of the dump.
+
+ANALYSIS
+========
+
+You can run gdb on the dump file copied out of /proc/vmcore. Use vmlinux built
+with -g and run
+
+ gdb vmlinux <dump-file>
+
+Stack trace for the task on processor 0, register display, memory display
+work fine.
+
+TODO
+====
+
+1) Provide a kernel-pages only view for the dump. This could possibly turn up
+ as /proc/vmcore-kern.
+2) Provide register contents of all processors (similar to what multi-threaded
+ core dumps does).
+3) Modify "crash" to make it recognize this dump.
+4) Make the i386 kernel boot from any location so we can run the second kernel
+ from the reserved location instead of the current approach.
+
+CONTACT
+=======
+
+Hariprasad Nellitheertha - hari at in dot ibm dot com
_
\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.109 / U:0.960 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site