GitHub-Mirror/linux-bl808
2
0
Fork 0
mirror of https://github.com/Fishwaldo/linux-bl808.git synced 2025-06-06 06:35:12 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

[PATCH] Kdump documentation update

Browse source 
Update the kdump documentation to reflect the changes due to recent kernel
config option changes for kexec and kdump.

Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This commit is contained in:
Maneesh Soni 2006-01-09 20:51:53 -08:00 • committed by Linus Torvalds
parent 05970d476f
commit a7e670d828
1 changed files with 73 additions and 64 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

125
Documentation/kdump/kdump.txt
View file

@ -4,10 +4,10 @@ Documentation for kdump - the kexec-based crash dumping solution
DESIGN DESIGN
====== ======
Kdump uses kexec to reboot to a second kernel whenever a dump needs to be taken. Kdump uses kexec to reboot to a second kernel whenever a dump needs to be
This second kernel is booted with very little memory. The first kernel reserves taken. This second kernel is booted with very little memory. The first kernel
the section of memory that the second kernel uses. This ensures that on-going reserves the section of memory that the second kernel uses. This ensures that
DMA from the first kernel does not corrupt the second kernel. on-going DMA from the first kernel does not corrupt the second kernel.
All the necessary information about Core image is encoded in ELF format and All the necessary information about Core image is encoded in ELF format and
stored in reserved area of memory before crash. Physical address of start of stored in reserved area of memory before crash. Physical address of start of
@ -35,77 +35,82 @@ In the second kernel, "old memory" can be accessed in two ways.
SETUP SETUP
===== =====
1) Download http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz 1) Download the upstream kexec-tools userspace package from
and apply http://lse.sourceforge.net/kdump/patches/kexec-tools-1.101-kdump.patch http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz.
and after that build the source.
2) Download and build the appropriate (2.6.13-rc1 onwards) vanilla kernel. Apply the latest consolidated kdump patch on top of kexec-tools-1.101
from http://lse.sourceforge.net/kdump/. This arrangment has been made
till all the userspace patches supporting kdump are integrated with
upstream kexec-tools userspace.
2) Download and build the appropriate (2.6.13-rc1 onwards) vanilla kernels.
Two kernels need to be built in order to get this feature working. Two kernels need to be built in order to get this feature working.
Following are the steps to properly configure the two kernels specific
to kexec and kdump features:
A) First kernel: A) First kernel or regular kernel:
----------------------------------
a) Enable "kexec system call" feature (in Processor type and features). a) Enable "kexec system call" feature (in Processor type and features).
CONFIG_KEXEC=y CONFIG_KEXEC=y
b) This kernel's physical load address should be the default value of b) Enable "sysfs file system support" (in Pseudo filesystems).
0x100000 (0x100000, 1 MB) (in Processor type and features).
CONFIG_PHYSICAL_START=0x100000
c) Enable "sysfs file system support" (in Pseudo filesystems).
CONFIG_SYSFS=y CONFIG_SYSFS=y
c) make
d) Boot into first kernel with the command line parameter "crashkernel=Y@X". d) Boot into first kernel with the command line parameter "crashkernel=Y@X".
Use appropriate values for X and Y. Y denotes how much memory to reserve Use appropriate values for X and Y. Y denotes how much memory to reserve
for the second kernel, and X denotes at what physical address the reserved for the second kernel, and X denotes at what physical address the
memory section starts. For example: "crashkernel=64M@16M". reserved memory section starts. For example: "crashkernel=64M@16M".
B) Second kernel:
a) Enable "kernel crash dumps" feature (in Processor type and features). B) Second kernel or dump capture kernel:
---------------------------------------
a) For i386 architecture enable Highmem support
CONFIG_HIGHMEM=y
b) Enable "kernel crash dumps" feature (under "Processor type and features")
CONFIG_CRASH_DUMP=y CONFIG_CRASH_DUMP=y
b) Specify a suitable value for "Physical address where the kernel is c) Make sure a suitable value for "Physical address where the kernel is
loaded" (in Processor type and features). Typically this value loaded" (under "Processor type and features"). By default this value
should be same as X (See option d) above, e.g., 16 MB or 0x1000000. is 0x1000000 (16MB) and it should be same as X (See option d above),
e.g., 16 MB or 0x1000000.
CONFIG_PHYSICAL_START=0x1000000 CONFIG_PHYSICAL_START=0x1000000
c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). d) Enable "/proc/vmcore support" (Optional, under "Pseudo filesystems").
CONFIG_PROC_VMCORE=y CONFIG_PROC_VMCORE=y
d) Disable SMP support and build a UP kernel (Until it is fixed).
CONFIG_SMP=n
e) Enable "Local APIC support on uniprocessors".
CONFIG_X86_UP_APIC=y
f) Enable "IO-APIC support on uniprocessors"
CONFIG_X86_UP_IOAPIC=y
Note: i) Options a) and b) depend upon "Configure standard kernel features 3) After booting to regular kernel or first kernel, load the second kernel
(for small systems)" (under General setup). using the following command:
ii) Option a) also depends on CONFIG_HIGHMEM (under Processor
type and features).
iii) Both option a) and b) are under "Processor type and features".
3) Boot into the first kernel. You are now ready to try out kexec-based crash
dumps.
4) Load the second kernel to be booted using:
kexec -p <second-kernel> --args-linux --elf32-core-headers kexec -p <second-kernel> --args-linux --elf32-core-headers
--append="root=<root-dev> init 1 irqpoll" --append="root=<root-dev> init 1 irqpoll maxcpus=1"
Note: i) <second-kernel> has to be a vmlinux image. bzImage will not work, Notes:
as of now. ======
ii) By default ELF headers are stored in ELF64 format. Option i) <second-kernel> has to be a vmlinux image ie uncompressed elf image.
--elf32-core-headers forces generation of ELF32 headers. gdb can bzImage will not work, as of now.
not open ELF64 headers on 32 bit systems. So creating ELF32 ii) --args-linux has to be speicfied as if kexec it loading an elf image,
headers can come handy for users who have got non-PAE systems and it needs to know that the arguments supplied are of linux type.
hence have memory less than 4GB. iii) By default ELF headers are stored in ELF64 format to support systems
iii) Specify "irqpoll" as command line parameter. This reduces driver with more than 4GB memory. Option --elf32-core-headers forces generation
of ELF32 headers. The reason for this option being, as of now gdb can
not open vmcore file with ELF64 headers on a 32 bit systems. So ELF32
headers can be used if one has non-PAE systems and hence memory less
than 4GB.
iv) Specify "irqpoll" as command line parameter. This reduces driver
initialization failures in second kernel due to shared interrupts. initialization failures in second kernel due to shared interrupts.
iv) <root-dev> needs to be specified in a format corresponding to v) <root-dev> needs to be specified in a format corresponding to the root
the root device name in the output of mount command. device name in the output of mount command.
v) If you have built the drivers required to mount root file vi) If you have built the drivers required to mount root file system as
system as modules in <second-kernel>, then, specify modules in <second-kernel>, then, specify
--initrd=<initrd-for-second-kernel>. --initrd=<initrd-for-second-kernel>.
vii) Specify maxcpus=1 as, if during first kernel run, if panic happens on
non-boot cpus, second kernel doesn't seem to be boot up all the cpus.
The other option is to always built the second kernel without SMP
support ie CONFIG_SMP=n
5) System reboots into the second kernel when a panic occurs. A module can be 4) After successfully loading the second kernel as above, if a panic occurs
written to force the panic or "ALT-SysRq-c" can be used initiate a crash system reboots into the second kernel. A module can be written to force
dump for testing purposes. the panic or "ALT-SysRq-c" can be used initiate a crash dump for testing
purposes.
6) Write out the dump file using 5) Once the second kernel has booted, write out the dump file using
cp /proc/vmcore <dump-file> cp /proc/vmcore <dump-file>
@ -119,9 +124,9 @@ SETUP
Entire memory: dd if=/dev/oldmem of=oldmem.001 Entire memory: dd if=/dev/oldmem of=oldmem.001
ANALYSIS ANALYSIS
======== ========
Limited analysis can be done using gdb on the dump file copied out of Limited analysis can be done using gdb on the dump file copied out of
/proc/vmcore. Use vmlinux built with -g and run /proc/vmcore. Use vmlinux built with -g and run
@ -132,15 +137,19 @@ work fine.
Note: gdb cannot analyse core files generated in ELF64 format for i386. Note: gdb cannot analyse core files generated in ELF64 format for i386.
Latest "crash" (crash-4.0-2.18) as available on Dave Anderson's site
http://people.redhat.com/~anderson/ works well with kdump format.
TODO TODO
==== ====
1) Provide a kernel pages filtering mechanism so that core file size is not 1) Provide a kernel pages filtering mechanism so that core file size is not
insane on systems having huge memory banks. insane on systems having huge memory banks.
2) Modify "crash" tool to make it recognize this dump. 2) Relocatable kernel can help in maintaining multiple kernels for crashdump
and same kernel as the first kernel can be used to capture the dump.
CONTACT CONTACT
======= =======
Vivek Goyal (vgoyal@in.ibm.com) Vivek Goyal (vgoyal@in.ibm.com)
Maneesh Soni (maneesh@in.ibm.com) Maneesh Soni (maneesh@in.ibm.com)