Doug / smarc-fsl-linux-kernel

Download as
Browse Code ยป

Commit a7e670d828e85ef9aacb7fa1cd221525c408110f

Authored by Maneesh Soni
Committed by Linus Torvalds
1 parent 05970d476f
Exists in master and in 7 other branches imx_3.0.35_4.1.0, imx_3.10.17_1.0.1_ga, imx_3.10.53_1.1.0_ga, imx_3.14.28_1.0.0_ga, smarc-imx_3.10.53_1.1.0_ga, smarc-imx_3.14.28_1.0.0_ga, smarc-l5.0.0_1.0.0-ga

[PATCH] Kdump documentation update 

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>

Showing 1 changed file with 79 additions and 70 deletions Side-by-side Diff

Documentation/kdump/kdump.txt
Diff comments   View file @ a7e670d
... ... @@ -4,10 +4,10 @@
4 4 DESIGN
5 5 ======
6 6  
7   -Kdump uses kexec to reboot to a second kernel whenever a dump needs to be taken.
8   -This second kernel is booted with very little memory. The first kernel reserves
9   -the section of memory that the second kernel uses. This ensures that on-going
10   -DMA from the first kernel does not corrupt the second kernel.
  7 +Kdump uses kexec to reboot to a second kernel whenever a dump needs to be
  8 +taken. This second kernel is booted with very little memory. The first kernel
  9 +reserves the section of memory that the second kernel uses. This ensures that
  10 +on-going DMA from the first kernel does not corrupt the second kernel.
11 11  
12 12 All the necessary information about Core image is encoded in ELF format and
13 13 stored in reserved area of memory before crash. Physical address of start of
14 14  
15 15  
16 16  
17 17  
18 18  
19 19  
20 20  
21 21  
22 22  
23 23  
24 24  
25 25  
26 26  
27 27  
... ... @@ -35,77 +35,82 @@
35 35 SETUP
36 36 =====
37 37  
38   -1) Download http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz
39   - and apply http://lse.sourceforge.net/kdump/patches/kexec-tools-1.101-kdump.patch
40   - and after that build the source.
  38 +1) Download the upstream kexec-tools userspace package from
  39 + http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz.
41 40  
42   -2) Download and build the appropriate (2.6.13-rc1 onwards) vanilla kernel.
  41 + Apply the latest consolidated kdump patch on top of kexec-tools-1.101
  42 + from http://lse.sourceforge.net/kdump/. This arrangment has been made
  43 + till all the userspace patches supporting kdump are integrated with
  44 + upstream kexec-tools userspace.
43 45  
  46 +2) Download and build the appropriate (2.6.13-rc1 onwards) vanilla kernels.
44 47 Two kernels need to be built in order to get this feature working.
  48 + Following are the steps to properly configure the two kernels specific
  49 + to kexec and kdump features:
45 50  
46   - A) First kernel:
  51 + A) First kernel or regular kernel:
  52 + ----------------------------------
47 53 a) Enable "kexec system call" feature (in Processor type and features).
48   - CONFIG_KEXEC=y
49   - b) This kernel's physical load address should be the default value of
50   - 0x100000 (0x100000, 1 MB) (in Processor type and features).
51   - CONFIG_PHYSICAL_START=0x100000
52   - c) Enable "sysfs file system support" (in Pseudo filesystems).
53   - CONFIG_SYSFS=y
  54 + CONFIG_KEXEC=y
  55 + b) Enable "sysfs file system support" (in Pseudo filesystems).
  56 + CONFIG_SYSFS=y
  57 + c) make
54 58 d) Boot into first kernel with the command line parameter "crashkernel=Y@X".
55 59 Use appropriate values for X and Y. Y denotes how much memory to reserve
56   - for the second kernel, and X denotes at what physical address the reserved
57   - memory section starts. For example: "crashkernel=64M@16M".
  60 + for the second kernel, and X denotes at what physical address the
  61 + reserved memory section starts. For example: "crashkernel=64M@16M".
58 62  
59   - B) Second kernel:
60   - a) Enable "kernel crash dumps" feature (in Processor type and features).
61   - CONFIG_CRASH_DUMP=y
62   - b) Specify a suitable value for "Physical address where the kernel is
63   - loaded" (in Processor type and features). Typically this value
64   - should be same as X (See option d) above, e.g., 16 MB or 0x1000000.
65   - CONFIG_PHYSICAL_START=0x1000000
66   - c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems).
67   - CONFIG_PROC_VMCORE=y
68   - d) Disable SMP support and build a UP kernel (Until it is fixed).
69   - CONFIG_SMP=n
70   - e) Enable "Local APIC support on uniprocessors".
71   - CONFIG_X86_UP_APIC=y
72   - f) Enable "IO-APIC support on uniprocessors"
73   - CONFIG_X86_UP_IOAPIC=y
74 63  
75   - Note: i) Options a) and b) depend upon "Configure standard kernel features
76   - (for small systems)" (under General setup).
77   - ii) Option a) also depends on CONFIG_HIGHMEM (under Processor
78   - type and features).
79   - iii) Both option a) and b) are under "Processor type and features".
  64 + B) Second kernel or dump capture kernel:
  65 + ---------------------------------------
  66 + a) For i386 architecture enable Highmem support
  67 + CONFIG_HIGHMEM=y
  68 + b) Enable "kernel crash dumps" feature (under "Processor type and features")
  69 + CONFIG_CRASH_DUMP=y
  70 + c) Make sure a suitable value for "Physical address where the kernel is
  71 + loaded" (under "Processor type and features"). By default this value
  72 + is 0x1000000 (16MB) and it should be same as X (See option d above),
  73 + e.g., 16 MB or 0x1000000.
  74 + CONFIG_PHYSICAL_START=0x1000000
  75 + d) Enable "/proc/vmcore support" (Optional, under "Pseudo filesystems").
  76 + CONFIG_PROC_VMCORE=y
80 77  
81   -3) Boot into the first kernel. You are now ready to try out kexec-based crash
82   - dumps.
  78 +3) After booting to regular kernel or first kernel, load the second kernel
  79 + using the following command:
83 80  
84   -4) Load the second kernel to be booted using:
85   -
86 81 kexec -p <second-kernel> --args-linux --elf32-core-headers
87   - --append="root=<root-dev> init 1 irqpoll"
  82 + --append="root=<root-dev> init 1 irqpoll maxcpus=1"
88 83  
89   - Note: i) <second-kernel> has to be a vmlinux image. bzImage will not work,
90   - as of now.
91   - ii) By default ELF headers are stored in ELF64 format. Option
92   - --elf32-core-headers forces generation of ELF32 headers. gdb can
93   - not open ELF64 headers on 32 bit systems. So creating ELF32
94   - headers can come handy for users who have got non-PAE systems and
95   - hence have memory less than 4GB.
96   - iii) Specify "irqpoll" as command line parameter. This reduces driver
97   - initialization failures in second kernel due to shared interrupts.
98   - iv) <root-dev> needs to be specified in a format corresponding to
99   - the root device name in the output of mount command.
100   - v) If you have built the drivers required to mount root file
101   - system as modules in <second-kernel>, then, specify
102   - --initrd=<initrd-for-second-kernel>.
  84 + Notes:
  85 + ======
  86 + i) <second-kernel> has to be a vmlinux image ie uncompressed elf image.
  87 + bzImage will not work, as of now.
  88 + ii) --args-linux has to be speicfied as if kexec it loading an elf image,
  89 + it needs to know that the arguments supplied are of linux type.
  90 + iii) By default ELF headers are stored in ELF64 format to support systems
  91 + with more than 4GB memory. Option --elf32-core-headers forces generation
  92 + of ELF32 headers. The reason for this option being, as of now gdb can
  93 + not open vmcore file with ELF64 headers on a 32 bit systems. So ELF32
  94 + headers can be used if one has non-PAE systems and hence memory less
  95 + than 4GB.
  96 + iv) Specify "irqpoll" as command line parameter. This reduces driver
  97 + initialization failures in second kernel due to shared interrupts.
  98 + v) <root-dev> needs to be specified in a format corresponding to the root
  99 + device name in the output of mount command.
  100 + vi) If you have built the drivers required to mount root file system as
  101 + modules in <second-kernel>, then, specify
  102 + --initrd=<initrd-for-second-kernel>.
  103 + vii) Specify maxcpus=1 as, if during first kernel run, if panic happens on
  104 + non-boot cpus, second kernel doesn't seem to be boot up all the cpus.
  105 + The other option is to always built the second kernel without SMP
  106 + support ie CONFIG_SMP=n
103 107  
104   -5) System reboots into the second kernel when a panic occurs. A module can be
105   - written to force the panic or "ALT-SysRq-c" can be used initiate a crash
106   - dump for testing purposes.
  108 +4) After successfully loading the second kernel as above, if a panic occurs
  109 + system reboots into the second kernel. A module can be written to force
  110 + the panic or "ALT-SysRq-c" can be used initiate a crash dump for testing
  111 + purposes.
107 112  
108   -6) Write out the dump file using
  113 +5) Once the second kernel has booted, write out the dump file using
109 114  
110 115 cp /proc/vmcore <dump-file>
111 116  
112 117  
... ... @@ -119,9 +124,9 @@
119 124  
120 125 Entire memory: dd if=/dev/oldmem of=oldmem.001
121 126  
  127 +
122 128 ANALYSIS
123 129 ========
124   -
125 130 Limited analysis can be done using gdb on the dump file copied out of
126 131 /proc/vmcore. Use vmlinux built with -g and run
127 132  
128 133  
129 134  
130 135  
131 136  
... ... @@ -132,16 +137,20 @@
132 137  
133 138 Note: gdb cannot analyse core files generated in ELF64 format for i386.
134 139  
  140 +Latest "crash" (crash-4.0-2.18) as available on Dave Anderson's site
  141 +http://people.redhat.com/~anderson/ works well with kdump format.
  142 +
  143 +
135 144 TODO
136 145 ====
137   -
138 146 1) Provide a kernel pages filtering mechanism so that core file size is not
139 147 insane on systems having huge memory banks.
140   -2) Modify "crash" tool to make it recognize this dump.
  148 +2) Relocatable kernel can help in maintaining multiple kernels for crashdump
  149 + and same kernel as the first kernel can be used to capture the dump.
141 150  
  151 +
142 152 CONTACT
143 153 =======
144   -
145 154 Vivek Goyal (vgoyal@in.ibm.com)
146 155 Maneesh Soni (maneesh@in.ibm.com)