Lines Matching +full:in +full:- +full:kernel
2 Firmware-Assisted Dump
7 The goal of firmware-assisted dump is to enable the dump of
8 a crashed system, and to do so from a fully-reset system, and
10 in production use.
12 - Firmware-Assisted Dump (FADump) infrastructure is intended to replace
14 - Fadump uses the same firmware interfaces and memory reservation model
16 - Unlike phyp dump, FADump exports the memory dump through /proc/vmcore
17 in the ELF format in the same way as kdump. This helps us reuse the
19 - Unlike phyp dump, userspace tool does not need to refer any sysfs
21 - Unlike phyp dump, FADump allows user to release all the memory reserved
22 for dump, with a single operation of echo 1 > /sys/kernel/fadump_release_mem.
23 - Once enabled through kernel boot parameter, FADump can be
24 started/stopped through /sys/kernel/fadump_registered interface (see
28 Comparing with kdump or other strategies, firmware-assisted
31 - Unlike kdump, the system has been reset, and loaded
32 with a fresh copy of the kernel. In particular,
34 in a clean, consistent state.
35 - Once the dump is copied out, the memory that held the dump
36 is immediately available to the running kernel. And therefore,
44 - The first kernel registers the sections of memory with the
47 kernel during early boot.
49 - When system crashes, the Power firmware will copy the registered
55 that is required for a kernel to boot successfully when
61 boot memory size is not sufficient for second kernel to
63 refer to Documentation/admin-guide/kdump/kdump.rst. If any
64 offset is provided in crashkernel= parameter, it will be
66 for boot memory dump preservation in case of a crash.
68 - After the low memory (boot memory) area has been saved, the
73 - The freshly booted kernel will notice that there is a new node
74 (rtas/ibm,kernel-dump on pSeries or ibm,opal/dump/mpipl-boot
75 on OPAL platform) in the device tree, indicating that
79 size. This will make sure that this kernel (also, referred
80 to as second kernel or capture kernel) will not touch any
83 - User-space tools will read /proc/vmcore to obtain the contents
84 of memory, which holds the previous crashed kernel dump in ELF
88 - Once the userspace tool is done saving dump, it will echo
89 '1' to /sys/kernel/fadump_release_mem to release the reserved
91 next firmware-assisted dump registration.
95 # echo 1 > /sys/kernel/fadump_release_mem
97 Please note that the firmware-assisted dump feature
105 kernel (referred to as petitboot kernel) before booting into the
106 capture kernel. This kernel would have minimal kernel and/or
107 userspace support to process crash data. Such kernel needs to
108 preserve previously crash'ed kernel's memory for the subsequent
109 capture kernel boot to process this crash data. Kernel config
110 option CONFIG_PRESERVE_FA_DUMP has to be enabled on such kernel
113 -- On OPAL based machines (PowerNV), if the kernel is build with
116 helpful in debugging OPAL crashes with GDB. The kernel memory
124 -----------------------
133 /sys/kernel/fadump_release_mem file is created, and the reserved
141 for a copy of the boot memory content in addition to CPU state and
142 HPTE region, in the case a crash does occur.
145 there is no point in blocking this significant chunk of memory from
146 production kernel. Hence, the implementation uses the Linux kernel's
148 configured for kernel. With CMA reservation this memory will be
149 available for applications to use it, while kernel is prevented from
151 kernel memory and most of the user space memory except the user pages
152 that were present in CMA region::
154 o Memory Reservation during first kernel
157 0 boot memory size |<--- Reserved dump area --->| |
160 +-----------+-----/ /---+---+----+-------+-----+-----+----+--+
162 +-----------+-----/ /---+---+----+-------+-----+-----+----+--+
166 ------------------------------ | |
175 address is registered with f/w and retrieved in the
176 second kernel after crash, on platforms that support
183 o Memory Reservation during second kernel after crash
187 | |<------------ Crash preserved area ------------>|
188 V V |<--- Reserved dump area --->| |
189 +-----------+-----/ /---+---+----+-------+-----+-----+----+--+
191 +-----------+-----/ /---+---+----+-------+-----+-----+----+--+
195 kernel to boot
197 +---+
198 |///| -> Regions (CPU, HPTE & Metadata) marked like this in the above
199 +---+ figures are not always present. For example, OPAL platform
208 in ELF format. Hence the existing kdump infrastructure (kdump scripts)
211 user intervention in saving the dump) when FADump is used, instead of
217 How to enable firmware-assisted dump (FADump):
218 ----------------------------------------------
220 1. Set config option CONFIG_FA_DUMP=y and build kernel.
221 2. Boot into linux kernel with 'fadump=on' kernel cmdline option.
223 Alternatively, user can boot linux kernel with 'fadump=nocma' to
225 3. Optionally, user can also set 'crashkernel=' kernel cmdline
233 2. If firmware-assisted dump fails to reserve memory then it
235 option is set at kernel cmdline.
238 'fadump=nocma' kernel parameter can be used to fallback to
242 --------------------
244 Firmware-assisted dump feature uses sysfs file system to hold
247 Here is the list of files under kernel sysfs:
249 /sys/kernel/fadump_enabled
252 - 0 = FADump is disabled
253 - 1 = FADump is enabled
256 FADump is enabled in the kernel and act accordingly.
258 /sys/kernel/fadump_registered
262 - 0 = FADump is not registered.
263 - 1 = FADump is registered and ready to handle system crash.
265 To register FADump echo 1 > /sys/kernel/fadump_registered and
266 echo 0 > /sys/kernel/fadump_registered for un-register and stop the
267 FADump. Once the FADump is un-registered, the system crash will not
271 /sys/kernel/fadump/mem_reserved
276 /sys/kernel/fadump_release_mem
278 second kernel. This is used to release the reserved memory
282 echo 1 > /sys/kernel/fadump_release_mem
284 After echo 1, the content of the /sys/kernel/debug/powerpc/fadump_region
291 Note: /sys/kernel/fadump_release_opalcore sysfs has moved to
297 active during capture kernel. This is used to release the memory
298 used by the kernel to export /sys/firmware/opal/mpipl/core file. To
305 +----------------------------------+--------------------------------+
307 +----------------------------------+--------------------------------+
308 | /sys/kernel/fadump_enabled | /sys/kernel/fadump/enabled |
309 +----------------------------------+--------------------------------+
310 | /sys/kernel/fadump_registered | /sys/kernel/fadump/registered |
311 +----------------------------------+--------------------------------+
312 | /sys/kernel/fadump_release_mem | /sys/kernel/fadump/release_mem |
313 +----------------------------------+--------------------------------+
316 (Assuming debugfs is mounted on /sys/kernel/debug directory.)
318 /sys/kernel/debug/powerpc/fadump_region
323 <region>: [<start>-<end>] <reserved-size> bytes, Dumped: <dump-size>
325 and for kernel DUMP region is:
327 DUMP: Src: <src-addr>, Dest: <dest-addr>, Size: <size>, Dumped: # bytes
330 Contents when FADump is registered during first kernel::
332 # cat /sys/kernel/debug/powerpc/fadump_region
333 CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x0
334 HPTE: [0x0000006fff0020-0x0000006fff101f] 0x1000 bytes, Dumped: 0x0
335 DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x0
337 Contents when FADump is active during second kernel::
339 # cat /sys/kernel/debug/powerpc/fadump_region
340 CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x40020
341 HPTE: [0x0000006fff0020-0x0000006fff101f] 0x1000 bytes, Dumped: 0x1000
342 DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x10000000
343 : [0x00000010000000-0x0000006ffaffff] 0x5ffb0000 bytes, Dumped: 0x5ffb0000
352 -----
353 - Need to come up with the better approach to find out more
354 accurate boot memory size that is required for a kernel to
356 - The FADump implementation introduces a FADump crash info structure
357 in the scratch area before the ELF core header. The idea of introducing
359 kernel which will help second kernel to populate ELF core header with
362 additional fields (in future) to this structure without affecting
368 whenever a new field is added to the structure in future. The version