Lines Matching +full:memory +full:- +full:to +full:- +full:memory

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
9 to minimize the total elapsed time until the system is back
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
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
23 - Once enabled through kernel boot parameter, FADump can be
28 Comparing with kdump or other strategies, firmware-assisted
31 - Unlike kdump, the system has been reset, and loaded
35 - Once the dump is copied out, the memory that held the dump
36 is immediately available to the running kernel. And therefore,
37 unlike kdump, FADump doesn't need a 2nd reboot to get back
38 the system to the production configuration.
44 - The first kernel registers the sections of memory with the
46 These registered sections of memory are reserved by the first
49 - When system crashes, the Power firmware will copy the registered
50 low memory regions (boot memory) from source to destination area.
54 The term 'boot memory' means size of the low memory chunk
55 that is required for a kernel to boot successfully when
56 booted with restricted memory. By default, the boot memory
58 Alternatively, user can also specify boot memory size
61 boot memory size is not sufficient for second kernel to
63 refer to Documentation/admin-guide/kdump/kdump.rst. If any
65 ignored as FADump uses a predefined offset to reserve memory
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
77 the early boot OS will reserve rest of the memory above
78 boot memory size effectively booting with restricted memory
80 to as second kernel or capture kernel) will not touch any
81 of the dump memory area.
83 - User-space tools will read /proc/vmcore to obtain the contents
84 of memory, which holds the previous crashed kernel dump in ELF
85 format. The userspace tools may copy this info to disk, or
88 - Once the userspace tool is done saving dump, it will echo
89 '1' to /sys/kernel/fadump_release_mem to release the reserved
90 memory back to general use, except the memory required for
91 next firmware-assisted dump registration.
97 Please note that the firmware-assisted dump feature
105 kernel (referred to as petitboot kernel) before booting into the
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
111 to ensure that crash data is preserved to process later.
113 -- On OPAL based machines (PowerNV), if the kernel is build with
114 CONFIG_OPAL_CORE=y, OPAL memory at the time of crash is also
116 helpful in debugging OPAL crashes with GDB. The kernel memory
118 '1' to /sys/firmware/opal/mpipl/release_core node.
123 -- Support for Additional Kernel Arguments in Fadump
125 to the fadump kernel. This feature was primarily designed to disable
127 and to reduce its memory footprint while collecting the dump.
129 Command to Add Additional Kernel Parameters to Fadump:
133 The above command is sufficient to add additional arguments to fadump.
136 Command to Retrieve the Additional Fadump Arguments:
146 -----------------------
148 During boot, a check is made to see if firmware supports
150 we check to see if an active dump is waiting for us. If yes
151 then everything but boot memory size of RAM is reserved during
156 memory is held.
158 If there is no waiting dump data, then only the memory required to
159 hold CPU state, HPTE region, boot memory dump, and FADump header is
160 usually reserved at an offset greater than boot memory size (see Fig. 1).
163 memory content in addition to CPU state and HPTE region, in the case
166 Since this reserved memory area is used only after the system crash,
167 there is no point in blocking this significant chunk of memory from
169 Contiguous Memory Allocator (CMA) for memory reservation if CMA is
170 configured for kernel. With CMA reservation this memory will be
171 available for applications to use it, while kernel is prevented from
172 using it. With this FADump will still be able to capture all of the
173 kernel memory and most of the user space memory except the user pages
176 o Memory Reservation during first kernel
178 Low memory Top of memory
179 0 boot memory size |<------ Reserved dump area ----->| |
182 +-----------+-----/ /---+---+----+-----------+-------+----+-----+
184 +-----------+-----/ /---+---+----+-----------+-------+----+-----+
188 -------------------------------- | |
189 Boot memory content gets transferred | |
190 to reserved area by firmware at the | |
200 to process the crashdump eases dump capture process.
205 o Memory Reservation during second kernel after crash
207 Low memory Top of memory
208 0 boot memory size |
209 | |<------------ Crash preserved area ------------>|
210 V V |<--- Reserved dump area --->| |
211 +----+---+--+-----/ /---+---+----+-------+-----+-----+-------+
213 +----+---+--+-----/ /---+---+----+-------+-----+-----+-------+
215 ----- ------------------------------ ---------------
219 \ | ----------------------------
226 +---+
227 |///| -> Regions (CPU, HPTE & Metadata) marked like this in the above
228 +---+ figures are not always present. For example, OPAL platform
232 +---+
233 |ELF| -> elfcorehdr, it is created in second kernel after crash.
234 +---+
236 Note: Memory from 0 to the boot memory size is used by second kernel
241 Currently the dump will be copied from /proc/vmcore to a new file upon
244 to save the dump works fine with minor modifications. KDump scripts on
245 major Distro releases have already been modified to work seamlessly (no
249 The tools to examine the dump will be same as the ones
252 How to enable firmware-assisted dump (FADump):
253 ----------------------------------------------
257 By default, FADump reserved memory will be initialized as CMA area.
258 Alternatively, user can boot linux kernel with 'fadump=nocma' to
259 prevent FADump to use CMA.
261 to specify size of the memory to reserve for boot memory dump
266 use 'crashkernel=' to specify size of the memory to reserve
267 for boot memory dump preservation.
268 2. If firmware-assisted dump fails to reserve memory then it
269 will fallback to existing kdump mechanism if 'crashkernel='
271 3. if user wants to capture all of user space memory and ok with
272 reserved memory not available to production system, then
273 'fadump=nocma' kernel parameter can be used to fallback to
277 --------------------
279 Firmware-assisted dump feature uses sysfs file system to hold
280 the control files and debugfs file to display memory reserved region.
285 This is used to display the FADump status.
287 - 0 = FADump is disabled
288 - 1 = FADump is enabled
290 This interface can be used by kdump init scripts to identify if
294 This is used to display the FADump registration status as well
295 as to control (start/stop) the FADump registration.
297 - 0 = FADump is not registered.
298 - 1 = FADump is registered and ready to handle system crash.
300 To register FADump echo 1 > /sys/kernel/fadump_registered and
301 echo 0 > /sys/kernel/fadump_registered for un-register and stop the
302 FADump. Once the FADump is un-registered, the system crash will not
308 This is used to display the memory reserved by FADump for saving the
313 second kernel. This is used to release the reserved memory
314 region that are held for saving crash dump. To release the
315 reserved memory echo 1 to it::
320 file will change to reflect the new memory reservations.
323 enhanced to use this interface to release the memory reserved for
326 Note: /sys/kernel/fadump_release_opalcore sysfs has moved to
332 active during capture kernel. This is used to release the memory
333 used by the kernel to export /sys/firmware/opal/mpipl/core file. To
334 release this memory, echo '1' to it:
340 +----------------------------------+--------------------------------+
342 +----------------------------------+--------------------------------+
344 +----------------------------------+--------------------------------+
346 +----------------------------------+--------------------------------+
348 +----------------------------------+--------------------------------+
354 This file shows the reserved memory regions if FADump is
358 <region>: [<start>-<end>] <reserved-size> bytes, Dumped: <dump-size>
362 DUMP: Src: <src-addr>, Dest: <dest-addr>, Size: <size>, Dumped: # bytes
368 CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x0
369 HPTE: [0x0000006fff0020-0x0000006fff101f] 0x1000 bytes, Dumped: 0x0
370 DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x0
375 CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x40020
376 HPTE: [0x0000006fff0020-0x0000006fff101f] 0x1000 bytes, Dumped: 0x1000
377 DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x10000000
378 : [0x00000010000000-0x0000006ffaffff] 0x5ffb0000 bytes, Dumped: 0x5ffb0000
382 Please refer to Documentation/filesystems/debugfs.rst on
383 how to mount the debugfs filesystem.
387 -----
388 - Need to come up with the better approach to find out more
389 accurate boot memory size that is required for a kernel to
390 boot successfully when booted with restricted memory.