Commit 8468d155 authored by Hari Bathini's avatar Hari Bathini Committed by Michael Ellerman

powerpc/fadump: Improve fadump documentation

The figures depicting FADump's (Firmware-Assisted Dump) memory layout
are missing some finer details like different memory regions and what
they represent. Improve the documentation by updating those details.
Signed-off-by: default avatarHari Bathini <hbathini@linux.ibm.com>
Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/156821322070.5656.8194734198500730487.stgit@hbathini.in.ibm.com
parent 7f0ad11d
......@@ -76,8 +76,9 @@ as follows:
there is crash data available from a previous boot. During
the early boot OS will reserve rest of the memory above
boot memory size effectively booting with restricted memory
size. This will make sure that the second kernel will not
touch any of the dump memory area.
size. This will make sure that this kernel (also, referred
to as second kernel or capture kernel) will not touch any
of the dump memory area.
- User-space tools will read /proc/vmcore to obtain the contents
of memory, which holds the previous crashed kernel dump in ELF
......@@ -128,42 +129,46 @@ space memory except the user pages that were present in CMA region::
o Memory Reservation during first kernel
Low memory Top of memory
0 boot memory size |
| | |<--Reserved dump area -->| |
V V | Permanent Reservation | V
+-----------+----------/ /---+---+----+-----------+----+------+
| | |CPU|HPTE| DUMP |ELF | |
+-----------+----------/ /---+---+----+-----------+----+------+
| ^
| |
\ /
-------------------------------------------
Boot memory content gets transferred to
reserved area by firmware at the time of
crash
Low memory Top of memory
0 boot memory size |<--Reserved dump area --->| |
| | | (Permanent Reservation) | |
V V | | V
+-----------+----------/ /---+---+----+--------+---+----+------+
| | |CPU|HPTE| DUMP |HDR|ELF | |
+-----------+----------/ /---+---+----+--------+---+----+------+
| ^ ^
| | |
\ / |
----------------------------------- FADump Header
Boot memory content gets transferred (meta area)
to reserved area by firmware at the
time of crash
Fig. 1
o Memory Reservation during second kernel after crash
Low memory Top of memory
0 boot memory size |
| |<------------- Reserved dump area ----------- -->|
V V V
+-----------+----------/ /---+---+----+-----------+----+------+
| | |CPU|HPTE| DUMP |ELF | |
+-----------+----------/ /---+---+----+-----------+----+------+
Low memory Top of memory
0 boot memory size |
| |<----------- Crash preserved area --------------->|
V V |<-- Reserved dump area -->| V
+-----------+----------/ /---+---+----+--------+---+----+------+
| | |CPU|HPTE| DUMP |HDR|ELF | |
+-----------+----------/ /---+---+----+--------+---+----+------+
| |
V V
Used by second /proc/vmcore
kernel to boot
Fig. 2
Currently the dump will be copied from /proc/vmcore to a
a new file upon user intervention. The dump data available through
/proc/vmcore will be in ELF format. Hence the existing kdump
infrastructure (kdump scripts) to save the dump works fine with
minor modifications.
Currently the dump will be copied from /proc/vmcore to a new file upon
user intervention. The dump data available through /proc/vmcore will be
in ELF format. Hence the existing kdump infrastructure (kdump scripts)
to save the dump works fine with minor modifications. KDump scripts on
major Distro releases have already been modified to work seemlessly (no
user intervention in saving the dump) when FADump is used, instead of
KDump, as dump mechanism.
The tools to examine the dump will be same as the ones
used for kdump.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment