Commit | Line | Data |
---|---|---|
dc851a0f DW |
1 | ================================================================ |
2 | Documentation for Kdump - The kexec-based Crash Dumping Solution | |
b089f4a6 VG |
3 | ================================================================ |
4 | ||
dc851a0f DW |
5 | This document includes overview, setup and installation, and analysis |
6 | information. | |
b089f4a6 | 7 | |
dc851a0f DW |
8 | Overview |
9 | ======== | |
b089f4a6 | 10 | |
dc851a0f DW |
11 | Kdump uses kexec to quickly boot to a dump-capture kernel whenever a |
12 | dump of the system kernel's memory needs to be taken (for example, when | |
13 | the system panics). The system kernel's memory image is preserved across | |
14 | the reboot and is accessible to the dump-capture kernel. | |
b089f4a6 | 15 | |
f4e87570 | 16 | You can use common commands, such as cp and scp, to copy the |
dc851a0f DW |
17 | memory image to a dump file on the local disk, or across the network to |
18 | a remote system. | |
b089f4a6 | 19 | |
91302143 | 20 | Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64, |
0ceb7d88 | 21 | s390x, arm and arm64 architectures. |
b089f4a6 | 22 | |
dc851a0f DW |
23 | When the system kernel boots, it reserves a small section of memory for |
24 | the dump-capture kernel. This ensures that ongoing Direct Memory Access | |
25 | (DMA) from the system kernel does not corrupt the dump-capture kernel. | |
26 | The kexec -p command loads the dump-capture kernel into this reserved | |
27 | memory. | |
b089f4a6 | 28 | |
dc851a0f DW |
29 | On x86 machines, the first 640 KB of physical memory is needed to boot, |
30 | regardless of where the kernel loads. Therefore, kexec backs up this | |
31 | region just before rebooting into the dump-capture kernel. | |
b089f4a6 | 32 | |
30430134 SH |
33 | Similarly on PPC64 machines first 32KB of physical memory is needed for |
34 | booting regardless of where the kernel is loaded and to support 64K page | |
35 | size kexec backs up the first 64KB memory. | |
36 | ||
91302143 MH |
37 | For s390x, when kdump is triggered, the crashkernel region is exchanged |
38 | with the region [0, crashkernel region size] and then the kdump kernel | |
39 | runs in [0, crashkernel region size]. Therefore no relocatable kernel is | |
40 | needed for s390x. | |
41 | ||
dc851a0f DW |
42 | All of the necessary information about the system kernel's core image is |
43 | encoded in the ELF format, and stored in a reserved area of memory | |
44 | before a crash. The physical address of the start of the ELF header is | |
45 | passed to the dump-capture kernel through the elfcorehdr= boot | |
91302143 MH |
46 | parameter. Optionally the size of the ELF header can also be passed |
47 | when using the elfcorehdr=[size[KMG]@]offset[KMG] syntax. | |
48 | ||
dc851a0f | 49 | |
987bf6fe ZY |
50 | With the dump-capture kernel, you can access the memory image through |
51 | /proc/vmcore. This exports the dump as an ELF-format file that you can | |
52 | write out using file copy commands such as cp or scp. Further, you can | |
53 | use analysis tools such as the GNU Debugger (GDB) and the Crash tool to | |
54 | debug the dump file. This method ensures that the dump pages are correctly | |
55 | ordered. | |
dc851a0f DW |
56 | |
57 | ||
58 | Setup and Installation | |
59 | ====================== | |
60 | ||
9c61a446 VG |
61 | Install kexec-tools |
62 | ------------------- | |
dc851a0f DW |
63 | |
64 | 1) Login as the root user. | |
65 | ||
66 | 2) Download the kexec-tools user-space package from the following URL: | |
67 | ||
db6857c6 | 68 | http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools.tar.gz |
ea112bd5 | 69 | |
d84a52f6 | 70 | This is a symlink to the latest version. |
dc851a0f | 71 | |
d84a52f6 | 72 | The latest kexec-tools git tree is available at: |
dc851a0f | 73 | |
d67297ad MCC |
74 | - git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git |
75 | - http://www.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git | |
db6857c6 SH |
76 | |
77 | There is also a gitweb interface available at | |
78 | http://www.kernel.org/git/?p=utils/kernel/kexec/kexec-tools.git | |
d84a52f6 SH |
79 | |
80 | More information about kexec-tools can be found at | |
b1bdd2eb | 81 | http://horms.net/projects/kexec/ |
dc851a0f | 82 | |
d67297ad | 83 | 3) Unpack the tarball with the tar command, as follows:: |
dc851a0f | 84 | |
d67297ad | 85 | tar xvpzf kexec-tools.tar.gz |
dc851a0f | 86 | |
d67297ad | 87 | 4) Change to the kexec-tools directory, as follows:: |
dc851a0f | 88 | |
d67297ad | 89 | cd kexec-tools-VERSION |
dc851a0f | 90 | |
d67297ad | 91 | 5) Configure the package, as follows:: |
dc851a0f | 92 | |
d67297ad | 93 | ./configure |
dc851a0f | 94 | |
d67297ad | 95 | 6) Compile the package, as follows:: |
dc851a0f | 96 | |
d67297ad | 97 | make |
dc851a0f | 98 | |
d67297ad | 99 | 7) Install the package, as follows:: |
dc851a0f | 100 | |
d67297ad | 101 | make install |
dc851a0f DW |
102 | |
103 | ||
9c61a446 VG |
104 | Build the system and dump-capture kernels |
105 | ----------------------------------------- | |
106 | There are two possible methods of using Kdump. | |
107 | ||
108 | 1) Build a separate custom dump-capture kernel for capturing the | |
109 | kernel core dump. | |
110 | ||
111 | 2) Or use the system kernel binary itself as dump-capture kernel and there is | |
112 | no need to build a separate dump-capture kernel. This is possible | |
19f59460 | 113 | only with the architectures which support a relocatable kernel. As |
a711bdc0 BB |
114 | of today, i386, x86_64, ppc64, ia64, arm and arm64 architectures support |
115 | relocatable kernel. | |
9c61a446 VG |
116 | |
117 | Building a relocatable kernel is advantageous from the point of view that | |
118 | one does not have to build a second kernel for capturing the dump. But | |
119 | at the same time one might want to build a custom dump capture kernel | |
120 | suitable to his needs. | |
dc851a0f | 121 | |
9c61a446 VG |
122 | Following are the configuration setting required for system and |
123 | dump-capture kernels for enabling kdump support. | |
dc851a0f | 124 | |
9c61a446 VG |
125 | System kernel config options |
126 | ---------------------------- | |
dc851a0f | 127 | |
d67297ad | 128 | 1) Enable "kexec system call" in "Processor type and features.":: |
dc851a0f | 129 | |
d67297ad | 130 | CONFIG_KEXEC=y |
dc851a0f DW |
131 | |
132 | 2) Enable "sysfs file system support" in "Filesystem" -> "Pseudo | |
d67297ad | 133 | filesystems." This is usually enabled by default:: |
dc851a0f | 134 | |
d67297ad | 135 | CONFIG_SYSFS=y |
dc851a0f DW |
136 | |
137 | Note that "sysfs file system support" might not appear in the "Pseudo | |
138 | filesystems" menu if "Configure standard kernel features (for small | |
139 | systems)" is not enabled in "General Setup." In this case, check the | |
d67297ad | 140 | .config file itself to ensure that sysfs is turned on, as follows:: |
dc851a0f | 141 | |
d67297ad | 142 | grep 'CONFIG_SYSFS' .config |
dc851a0f | 143 | |
d67297ad | 144 | 3) Enable "Compile the kernel with debug info" in "Kernel hacking.":: |
dc851a0f | 145 | |
d67297ad | 146 | CONFIG_DEBUG_INFO=Y |
dc851a0f DW |
147 | |
148 | This causes the kernel to be built with debug symbols. The dump | |
149 | analysis tools require a vmlinux with debug symbols in order to read | |
150 | and analyze a dump file. | |
151 | ||
9c61a446 VG |
152 | Dump-capture kernel config options (Arch Independent) |
153 | ----------------------------------------------------- | |
dc851a0f | 154 | |
9c61a446 | 155 | 1) Enable "kernel crash dumps" support under "Processor type and |
d67297ad | 156 | features":: |
dc851a0f | 157 | |
d67297ad | 158 | CONFIG_CRASH_DUMP=y |
dc851a0f | 159 | |
d67297ad MCC |
160 | 2) Enable "/proc/vmcore support" under "Filesystems" -> "Pseudo filesystems":: |
161 | ||
162 | CONFIG_PROC_VMCORE=y | |
b089f4a6 | 163 | |
9c61a446 | 164 | (CONFIG_PROC_VMCORE is set by default when CONFIG_CRASH_DUMP is selected.) |
dc851a0f | 165 | |
8bc9d422 BW |
166 | Dump-capture kernel config options (Arch Dependent, i386 and x86_64) |
167 | -------------------------------------------------------------------- | |
168 | ||
169 | 1) On i386, enable high memory support under "Processor type and | |
d67297ad MCC |
170 | features":: |
171 | ||
172 | CONFIG_HIGHMEM64G=y | |
173 | ||
174 | or:: | |
dc851a0f | 175 | |
d67297ad | 176 | CONFIG_HIGHMEM4G |
dc851a0f | 177 | |
8bc9d422 | 178 | 2) On i386 and x86_64, disable symmetric multi-processing support |
d67297ad | 179 | under "Processor type and features":: |
dc851a0f | 180 | |
d67297ad | 181 | CONFIG_SMP=n |
9c61a446 | 182 | |
dc851a0f DW |
183 | (If CONFIG_SMP=y, then specify maxcpus=1 on the kernel command line |
184 | when loading the dump-capture kernel, see section "Load the Dump-capture | |
185 | Kernel".) | |
186 | ||
9c61a446 VG |
187 | 3) If one wants to build and use a relocatable kernel, |
188 | Enable "Build a relocatable kernel" support under "Processor type and | |
d67297ad | 189 | features":: |
dc851a0f | 190 | |
d67297ad | 191 | CONFIG_RELOCATABLE=y |
dc851a0f | 192 | |
9c61a446 VG |
193 | 4) Use a suitable value for "Physical address where the kernel is |
194 | loaded" (under "Processor type and features"). This only appears when | |
195 | "kernel crash dumps" is enabled. A suitable value depends upon | |
196 | whether kernel is relocatable or not. | |
197 | ||
198 | If you are using a relocatable kernel use CONFIG_PHYSICAL_START=0x100000 | |
199 | This will compile the kernel for physical address 1MB, but given the fact | |
200 | kernel is relocatable, it can be run from any physical address hence | |
201 | kexec boot loader will load it in memory region reserved for dump-capture | |
202 | kernel. | |
203 | ||
204 | Otherwise it should be the start of memory region reserved for | |
205 | second kernel using boot parameter "crashkernel=Y@X". Here X is | |
206 | start of memory region reserved for dump-capture kernel. | |
207 | Generally X is 16MB (0x1000000). So you can set | |
208 | CONFIG_PHYSICAL_START=0x1000000 | |
209 | ||
210 | 5) Make and install the kernel and its modules. DO NOT add this kernel | |
211 | to the boot loader configuration files. | |
dc851a0f | 212 | |
9c61a446 VG |
213 | Dump-capture kernel config options (Arch Dependent, ppc64) |
214 | ---------------------------------------------------------- | |
dc851a0f | 215 | |
d67297ad | 216 | 1) Enable "Build a kdump crash kernel" support under "Kernel" options:: |
54622f10 | 217 | |
d67297ad | 218 | CONFIG_CRASH_DUMP=y |
54622f10 | 219 | |
d67297ad | 220 | 2) Enable "Build a relocatable kernel" support:: |
54622f10 | 221 | |
d67297ad | 222 | CONFIG_RELOCATABLE=y |
54622f10 MK |
223 | |
224 | Make and install the kernel and its modules. | |
dc851a0f | 225 | |
9c61a446 VG |
226 | Dump-capture kernel config options (Arch Dependent, ia64) |
227 | ---------------------------------------------------------- | |
ee8bb9ea H |
228 | |
229 | - No specific options are required to create a dump-capture kernel | |
19f59460 | 230 | for ia64, other than those specified in the arch independent section |
ee8bb9ea H |
231 | above. This means that it is possible to use the system kernel |
232 | as a dump-capture kernel if desired. | |
233 | ||
234 | The crashkernel region can be automatically placed by the system | |
235 | kernel at run time. This is done by specifying the base address as 0, | |
d67297ad | 236 | or omitting it all together:: |
ee8bb9ea | 237 | |
d67297ad MCC |
238 | crashkernel=256M@0 |
239 | ||
240 | or:: | |
241 | ||
242 | crashkernel=256M | |
ee8bb9ea H |
243 | |
244 | If the start address is specified, note that the start address of the | |
245 | kernel will be aligned to 64Mb, so if the start address is not then | |
246 | any space below the alignment point will be wasted. | |
9c61a446 | 247 | |
16b0371a H |
248 | Dump-capture kernel config options (Arch Dependent, arm) |
249 | ---------------------------------------------------------- | |
250 | ||
251 | - To use a relocatable kernel, | |
d67297ad | 252 | Enable "AUTO_ZRELADDR" support under "Boot" options:: |
16b0371a | 253 | |
d67297ad | 254 | AUTO_ZRELADDR=y |
9c61a446 | 255 | |
0ceb7d88 AT |
256 | Dump-capture kernel config options (Arch Dependent, arm64) |
257 | ---------------------------------------------------------- | |
258 | ||
259 | - Please note that kvm of the dump-capture kernel will not be enabled | |
260 | on non-VHE systems even if it is configured. This is because the CPU | |
261 | will not be reset to EL2 on panic. | |
262 | ||
fb391599 BW |
263 | Extended crashkernel syntax |
264 | =========================== | |
265 | ||
266 | While the "crashkernel=size[@offset]" syntax is sufficient for most | |
267 | configurations, sometimes it's handy to have the reserved memory dependent | |
268 | on the value of System RAM -- that's mostly for distributors that pre-setup | |
269 | the kernel command line to avoid a unbootable system after some memory has | |
270 | been removed from the machine. | |
271 | ||
d67297ad | 272 | The syntax is:: |
fb391599 BW |
273 | |
274 | crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset] | |
275 | range=start-[end] | |
276 | ||
d67297ad | 277 | For example:: |
fb391599 BW |
278 | |
279 | crashkernel=512M-2G:64M,2G-:128M | |
280 | ||
281 | This would mean: | |
282 | ||
283 | 1) if the RAM is smaller than 512M, then don't reserve anything | |
284 | (this is the "rescue" case) | |
be089d79 | 285 | 2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M |
fb391599 BW |
286 | 3) if the RAM size is larger than 2G, then reserve 128M |
287 | ||
288 | ||
be089d79 | 289 | |
9c61a446 VG |
290 | Boot into System Kernel |
291 | ======================= | |
292 | ||
30430134 SH |
293 | 1) Update the boot loader (such as grub, yaboot, or lilo) configuration |
294 | files as necessary. | |
9c61a446 VG |
295 | |
296 | 2) Boot the system kernel with the boot parameter "crashkernel=Y@X", | |
297 | where Y specifies how much memory to reserve for the dump-capture kernel | |
298 | and X specifies the beginning of this reserved memory. For example, | |
299 | "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory | |
300 | starting at physical address 0x01000000 (16MB) for the dump-capture kernel. | |
301 | ||
302 | On x86 and x86_64, use "crashkernel=64M@16M". | |
303 | ||
304 | On ppc64, use "crashkernel=128M@32M". | |
dc851a0f | 305 | |
ee8bb9ea H |
306 | On ia64, 256M@256M is a generous value that typically works. |
307 | The region may be automatically placed on ia64, see the | |
308 | dump-capture kernel config option notes above. | |
797f6a68 | 309 | If use sparse memory, the size should be rounded to GRANULE boundaries. |
ee8bb9ea | 310 | |
91302143 MH |
311 | On s390x, typically use "crashkernel=xxM". The value of xx is dependent |
312 | on the memory consumption of the kdump system. In general this is not | |
313 | dependent on the memory size of the production system. | |
314 | ||
61603016 RK |
315 | On arm, the use of "crashkernel=Y@X" is no longer necessary; the |
316 | kernel will automatically locate the crash kernel image within the | |
317 | first 512MB of RAM if X is not given. | |
16b0371a | 318 | |
0ceb7d88 AT |
319 | On arm64, use "crashkernel=Y[@X]". Note that the start address of |
320 | the kernel, X if explicitly specified, must be aligned to 2MiB (0x200000). | |
16b0371a | 321 | |
dc851a0f DW |
322 | Load the Dump-capture Kernel |
323 | ============================ | |
324 | ||
9c61a446 VG |
325 | After booting to the system kernel, dump-capture kernel needs to be |
326 | loaded. | |
327 | ||
328 | Based on the architecture and type of image (relocatable or not), one | |
329 | can choose to load the uncompressed vmlinux or compressed bzImage/vmlinuz | |
330 | of dump-capture kernel. Following is the summary. | |
331 | ||
8bc9d422 | 332 | For i386 and x86_64: |
d67297ad | 333 | |
9c61a446 VG |
334 | - Use vmlinux if kernel is not relocatable. |
335 | - Use bzImage/vmlinuz if kernel is relocatable. | |
d67297ad | 336 | |
9c61a446 | 337 | For ppc64: |
d67297ad | 338 | |
9c61a446 | 339 | - Use vmlinux |
d67297ad | 340 | |
9c61a446 | 341 | For ia64: |
d67297ad | 342 | |
ee8bb9ea | 343 | - Use vmlinux or vmlinuz.gz |
d67297ad | 344 | |
91302143 | 345 | For s390x: |
d67297ad | 346 | |
91302143 | 347 | - Use image or bzImage |
d67297ad | 348 | |
16b0371a | 349 | For arm: |
d67297ad | 350 | |
16b0371a | 351 | - Use zImage |
d67297ad | 352 | |
0ceb7d88 | 353 | For arm64: |
d67297ad | 354 | |
0ceb7d88 | 355 | - Use vmlinux or Image |
9c61a446 | 356 | |
a711bdc0 | 357 | If you are using an uncompressed vmlinux image then use following command |
d67297ad | 358 | to load dump-capture kernel:: |
dc851a0f | 359 | |
9c61a446 | 360 | kexec -p <dump-capture-kernel-vmlinux-image> \ |
dc851a0f | 361 | --initrd=<initrd-for-dump-capture-kernel> --args-linux \ |
9c61a446 | 362 | --append="root=<root-dev> <arch-specific-options>" |
dc851a0f | 363 | |
9c61a446 | 364 | If you are using a compressed bzImage/vmlinuz, then use following command |
d67297ad | 365 | to load dump-capture kernel:: |
dc851a0f | 366 | |
9c61a446 VG |
367 | kexec -p <dump-capture-kernel-bzImage> \ |
368 | --initrd=<initrd-for-dump-capture-kernel> \ | |
369 | --append="root=<root-dev> <arch-specific-options>" | |
370 | ||
16b0371a | 371 | If you are using a compressed zImage, then use following command |
d67297ad | 372 | to load dump-capture kernel:: |
16b0371a H |
373 | |
374 | kexec --type zImage -p <dump-capture-kernel-bzImage> \ | |
375 | --initrd=<initrd-for-dump-capture-kernel> \ | |
376 | --dtb=<dtb-for-dump-capture-kernel> \ | |
377 | --append="root=<root-dev> <arch-specific-options>" | |
378 | ||
a711bdc0 | 379 | If you are using an uncompressed Image, then use following command |
d67297ad | 380 | to load dump-capture kernel:: |
a711bdc0 BB |
381 | |
382 | kexec -p <dump-capture-kernel-Image> \ | |
383 | --initrd=<initrd-for-dump-capture-kernel> \ | |
384 | --append="root=<root-dev> <arch-specific-options>" | |
16b0371a | 385 | |
ee8bb9ea H |
386 | Please note, that --args-linux does not need to be specified for ia64. |
387 | It is planned to make this a no-op on that architecture, but for now | |
388 | it should be omitted | |
389 | ||
9c61a446 VG |
390 | Following are the arch specific command line options to be used while |
391 | loading dump-capture kernel. | |
392 | ||
ee8bb9ea | 393 | For i386, x86_64 and ia64: |
d67297ad | 394 | |
ac984abe | 395 | "1 irqpoll maxcpus=1 reset_devices" |
9c61a446 VG |
396 | |
397 | For ppc64: | |
d67297ad | 398 | |
ac984abe | 399 | "1 maxcpus=1 noirqdistrib reset_devices" |
dc851a0f | 400 | |
91302143 | 401 | For s390x: |
d67297ad | 402 | |
91302143 | 403 | "1 maxcpus=1 cgroup_disable=memory" |
9c61a446 | 404 | |
16b0371a | 405 | For arm: |
d67297ad | 406 | |
16b0371a H |
407 | "1 maxcpus=1 reset_devices" |
408 | ||
0ceb7d88 | 409 | For arm64: |
d67297ad | 410 | |
0ceb7d88 AT |
411 | "1 maxcpus=1 reset_devices" |
412 | ||
9c61a446 | 413 | Notes on loading the dump-capture kernel: |
dc851a0f DW |
414 | |
415 | * By default, the ELF headers are stored in ELF64 format to support | |
4fd45090 BW |
416 | systems with more than 4GB memory. On i386, kexec automatically checks if |
417 | the physical RAM size exceeds the 4 GB limit and if not, uses ELF32. | |
418 | So, on non-PAE systems, ELF32 is always used. | |
419 | ||
420 | The --elf32-core-headers option can be used to force the generation of ELF32 | |
421 | headers. This is necessary because GDB currently cannot open vmcore files | |
422 | with ELF64 headers on 32-bit systems. | |
dc851a0f DW |
423 | |
424 | * The "irqpoll" boot parameter reduces driver initialization failures | |
425 | due to shared interrupts in the dump-capture kernel. | |
426 | ||
427 | * You must specify <root-dev> in the format corresponding to the root | |
428 | device name in the output of mount command. | |
429 | ||
473e66fd H |
430 | * Boot parameter "1" boots the dump-capture kernel into single-user |
431 | mode without networking. If you want networking, use "3". | |
dc851a0f | 432 | |
a65fd4f0 | 433 | * We generally don't have to bring up a SMP kernel just to capture the |
9c61a446 VG |
434 | dump. Hence generally it is useful either to build a UP dump-capture |
435 | kernel or specify maxcpus=1 option while loading dump-capture kernel. | |
3dfb4c1b ZW |
436 | Note, though maxcpus always works, you had better replace it with |
437 | nr_cpus to save memory if supported by the current ARCH, such as x86. | |
dc851a0f | 438 | |
ebf137f6 ZW |
439 | * You should enable multi-cpu support in dump-capture kernel if you intend |
440 | to use multi-thread programs with it, such as parallel dump feature of | |
441 | makedumpfile. Otherwise, the multi-thread program may have a great | |
442 | performance degradation. To enable multi-cpu support, you should bring up an | |
443 | SMP dump-capture kernel and specify maxcpus/nr_cpus, disable_cpu_apicid=[X] | |
444 | options while loading it. | |
445 | ||
91302143 MH |
446 | * For s390x there are two kdump modes: If a ELF header is specified with |
447 | the elfcorehdr= kernel parameter, it is used by the kdump kernel as it | |
448 | is done on all other architectures. If no elfcorehdr= kernel parameter is | |
449 | specified, the s390x kdump kernel dynamically creates the header. The | |
450 | second mode has the advantage that for CPU and memory hotplug, kdump has | |
451 | not to be reloaded with kexec_load(). | |
452 | ||
453 | * For s390x systems with many attached devices the "cio_ignore" kernel | |
454 | parameter should be used for the kdump kernel in order to prevent allocation | |
455 | of kernel memory for devices that are not relevant for kdump. The same | |
456 | applies to systems that use SCSI/FCP devices. In that case the | |
457 | "allow_lun_scan" zfcp module parameter should be set to zero before | |
458 | setting FCP devices online. | |
459 | ||
dc851a0f DW |
460 | Kernel Panic |
461 | ============ | |
462 | ||
463 | After successfully loading the dump-capture kernel as previously | |
464 | described, the system will reboot into the dump-capture kernel if a | |
465 | system crash is triggered. Trigger points are located in panic(), | |
466 | die(), die_nmi() and in the sysrq handler (ALT-SysRq-c). | |
467 | ||
468 | The following conditions will execute a crash trigger point: | |
469 | ||
470 | If a hard lockup is detected and "NMI watchdog" is configured, the system | |
471 | will boot into the dump-capture kernel ( die_nmi() ). | |
472 | ||
473 | If die() is called, and it happens to be a thread with pid 0 or 1, or die() | |
474 | is called inside interrupt context or die() is called and panic_on_oops is set, | |
475 | the system will boot into the dump-capture kernel. | |
476 | ||
f4e87570 | 477 | On powerpc systems when a soft-reset is generated, die() is called by all cpus |
30430134 | 478 | and the system will boot into the dump-capture kernel. |
dc851a0f DW |
479 | |
480 | For testing purposes, you can trigger a crash by using "ALT-SysRq-c", | |
30430134 | 481 | "echo c > /proc/sysrq-trigger" or write a module to force the panic. |
dc851a0f DW |
482 | |
483 | Write Out the Dump File | |
484 | ======================= | |
485 | ||
486 | After the dump-capture kernel is booted, write out the dump file with | |
d67297ad | 487 | the following command:: |
b089f4a6 VG |
488 | |
489 | cp /proc/vmcore <dump-file> | |
490 | ||
dc851a0f DW |
491 | |
492 | Analysis | |
b089f4a6 | 493 | ======== |
b089f4a6 | 494 | |
dc851a0f DW |
495 | Before analyzing the dump image, you should reboot into a stable kernel. |
496 | ||
497 | You can do limited analysis using GDB on the dump file copied out of | |
498 | /proc/vmcore. Use the debug vmlinux built with -g and run the following | |
d67297ad | 499 | command:: |
dc851a0f DW |
500 | |
501 | gdb vmlinux <dump-file> | |
b089f4a6 | 502 | |
dc851a0f DW |
503 | Stack trace for the task on processor 0, register display, and memory |
504 | display work fine. | |
b089f4a6 | 505 | |
dc851a0f DW |
506 | Note: GDB cannot analyze core files generated in ELF64 format for x86. |
507 | On systems with a maximum of 4GB of memory, you can generate | |
508 | ELF32-format headers using the --elf32-core-headers kernel option on the | |
509 | dump kernel. | |
b089f4a6 | 510 | |
dc851a0f DW |
511 | You can also use the Crash utility to analyze dump files in Kdump |
512 | format. Crash is available on Dave Anderson's site at the following URL: | |
a7e670d8 | 513 | |
dc851a0f DW |
514 | http://people.redhat.com/~anderson/ |
515 | ||
9e3961a0 PB |
516 | Trigger Kdump on WARN() |
517 | ======================= | |
518 | ||
519 | The kernel parameter, panic_on_warn, calls panic() in all WARN() paths. This | |
520 | will cause a kdump to occur at the panic() call. In cases where a user wants | |
521 | to specify this during runtime, /proc/sys/kernel/panic_on_warn can be set to 1 | |
522 | to achieve the same behaviour. | |
dc851a0f | 523 | |
dc851a0f | 524 | Contact |
b089f4a6 | 525 | ======= |
dc851a0f | 526 | |
d67297ad MCC |
527 | - Vivek Goyal (vgoyal@redhat.com) |
528 | - Maneesh Soni (maneesh@in.ibm.com) | |
529 | ||
530 | GDB macros | |
531 | ========== | |
dc851a0f | 532 | |
d67297ad MCC |
533 | .. include:: gdbmacros.txt |
534 | :literal: |