Documentation/arch/powerpc/firmware-assisted-dump.rst

Source file repositories/reference/linux-study-clean/Documentation/arch/powerpc/firmware-assisted-dump.rst

File Facts

System
Linux kernel
Corpus path
Documentation/arch/powerpc/firmware-assisted-dump.rst
Extension
.rst
Size
17575 bytes
Lines
397
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

======================
Firmware-Assisted Dump
======================

July 2011

The goal of firmware-assisted dump is to enable the dump of
a crashed system, and to do so from a fully-reset system, and
to minimize the total elapsed time until the system is back
in production use.

- Firmware-Assisted Dump (FADump) infrastructure is intended to replace
  the existing phyp assisted dump.
- Fadump uses the same firmware interfaces and memory reservation model
  as phyp assisted dump.
- Unlike phyp dump, FADump exports the memory dump through /proc/vmcore
  in the ELF format in the same way as kdump. This helps us reuse the
  kdump infrastructure for dump capture and filtering.
- Unlike phyp dump, userspace tool does not need to refer any sysfs
  interface while reading /proc/vmcore.
- Unlike phyp dump, FADump allows user to release all the memory reserved
  for dump, with a single operation of echo 1 > /sys/kernel/fadump_release_mem.
- Once enabled through kernel boot parameter, FADump can be
  started/stopped through /sys/kernel/fadump_registered interface (see
  sysfs files section below) and can be easily integrated with kdump
  service start/stop init scripts.

Comparing with kdump or other strategies, firmware-assisted
dump offers several strong, practical advantages:

-  Unlike kdump, the system has been reset, and loaded
   with a fresh copy of the kernel.  In particular,
   PCI and I/O devices have been reinitialized and are
   in a clean, consistent state.
-  Once the dump is copied out, the memory that held the dump
   is immediately available to the running kernel. And therefore,
   unlike kdump, FADump doesn't need a 2nd reboot to get back
   the system to the production configuration.

The above can only be accomplished by coordination with,
and assistance from the Power firmware. The procedure is
as follows:

-  The first kernel registers the sections of memory with the
   Power firmware for dump preservation during OS initialization.
   These registered sections of memory are reserved by the first
   kernel during early boot.

-  When system crashes, the Power firmware will copy the registered
   low memory regions (boot memory) from source to destination area.
   It will also save hardware PTE's.

   NOTE:
         The term 'boot memory' means size of the low memory chunk
         that is required for a kernel to boot successfully when
         booted with restricted memory. By default, the boot memory
         size will be the larger of 5% of system RAM or 256MB.
         Alternatively, user can also specify boot memory size
         through boot parameter 'crashkernel=' which will override
         the default calculated size. Use this option if default
         boot memory size is not sufficient for second kernel to
         boot successfully. For syntax of crashkernel= parameter,
         refer to Documentation/admin-guide/kdump/kdump.rst. If any
         offset is provided in crashkernel= parameter, it will be
         ignored as FADump uses a predefined offset to reserve memory
         for boot memory dump preservation in case of a crash.

-  After the low memory (boot memory) area has been saved, the
   firmware will reset PCI and other hardware state.  It will
   *not* clear the RAM. It will then launch the bootloader, as

Annotation

Implementation Notes