https://www.kernel.org/doc/html/latest/admin-guide/ramoops.html
Ramoops oops/panic logger
Sergiu Iordache
Updated: 17 November 2011
Introduction
Ramoops is an oops/panic logger that writes its logs to RAM before the system crashes. It works by logging oopses and panics in a circular buffer. Ramoops needs a system with persistent RAM so that the content of that area can survive after a restart.
Ramoops is an oops / panic logger. You can write the log to RAM before the system crash. It records oopses and panis with a circular buffer. Ramoops requires a system with persistent RAM so that the contents of that area can be referenced even after a reboot.
Ramoops concepts
Ramoops uses a predefined memory area to store the dump. The start and size and type of the memory area are set using three variables:
Ramoops makes use of a predefined memory area to record dumps. Three variables are used to set the memory start position, size and type.
- mem_address for the start
--mem_address Memory start location --mem_size The size of the memory. The memory size is truncated to a power of 2. --mem_type Represents memory type (default is pgprot_writecombine)
Typically the default value of mem_type=0 should be used as that sets the pstore mapping to pgprot_writecombine. Setting mem_type=1 attempts to use pgprot_noncached, which only works on some platforms. This is because pstore depends on atomic operations. At least on ARM, pgprot_noncached causes the memory to be mapped strongly ordered, and atomic operations on strongly ordered memory are implementation defined, and won’t work on many ARMs such as omaps.
The default value of mem_type = 0 is typically used to set psore mapping to pgprot_writecombine. By setting mem_type = 1, pgprot_noncache will be used as a trial, but it can only be used on some systems. This is because pstore requires an atomic operation. At least on ARM, memory is strongly mapped by pgprot_noncached, and the atomic operation of strong ordered memory is an implementation definition and does not work on many ARMs such as omaps.
The memory area is divided into record_size chunks (also rounded down to power of two) and each oops/panic writes a record_size chunk of information.
The memory area is divided into record_size chunks (which are also truncated to powers of 2), and each oops / panic writes record_size chunks of information.
Dumping both oopses and panics can be done by setting 1 in the dump_oops variable while setting 0 in that variable dumps only the panics.
To dump oopses and panics, set the dump_oops variable to 1. If you set that variable to 0, you will only have panics.
The module uses a counter to record multiple dumps but the counter gets reset on restart (i.e. new dumps after the restart will overwrite old ones).
The module records multiple dumps, but the counter is reset after a reboot (that is, the new dump overwrites the old dump after a reboot).
Ramoops also supports software ECC protection of persistent memory regions. This might be useful when a hardware reset was used to bring the machine back to life (i.e. a watchdog triggered). In such cases, RAM may be somewhat corrupt, but usually it is restorable.
Ramoops also supports software ECC protection for persistent memory areas. This is useful if you used a hardware reset to restore the machine to its original state (that is, a watchdog occurred). In such cases, the RAM may be slightly corrupted, but it is usually recoverable.
Setting the parameters
Setting the ramoops parameters can be done in several different manners:
There are several ways to set the ramoops parameter.
A. Use the module parameters (which have the names of the variables described as before). For quick debugging, you can also reserve parts of memory during boot and then use the reserved memory for ramoops. For example, assuming a machine with > 128 MB of memory, the following kernel command line will tell the kernel to use only the first 128 MB of memory, and place ECC-protected ramoops region at 128 MB boundary:
A. How to use module parameter (use the variable name mentioned above). For easy debugging, you can reserve some of the memory at boot time and use the memory reserved for ramops. For example, if the machine has 128MB of memory, the kernel command line can tell you to use only the first 128MB of memory. It then tells the kernel to place the ramops region in ECC protected at the 128MB boundary.
mem=128M ramoops.mem_address=0x8000000 ramoops.ecc=1
B. Use Device Tree bindings, as described in Documentation/devicetree/bindings/reserved-memory/ramoops.txt. For example:
B. How to use Device Tree binding, which is described in Documentation / devicetree / bindings / reserved-memory / ramoops.txt. For example:
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
ramoops@8f000000 {
compatible = "ramoops";
reg = <0 0x8f000000 0 0x100000>;
record-size = <0x4000>;
console-size = <0x4000>;
};
};
C. Use a platform device and set the platform data. The parameters can then be set through that platform data. An example of doing that is:
C. How to set platform data using platform device. parameters can be set via that platform data. Here's an example of doing this:
#include <linux/pstore_ram.h>
[...]
static struct ramoops_platform_data ramoops_data = {
.mem_size = <...>,
.mem_address = <...>,
.mem_type = <...>,
.record_size = <...>,
.dump_oops = <...>,
.ecc = <...>,
};
static struct platform_device ramoops_dev = {
.name = "ramoops",
.dev = {
.platform_data = &ramoops_data,
},
};
[... inside a function ...]
int ret;
ret = platform_device_register(&ramoops_dev);
if (ret) {
printk(KERN_ERR "unable to register platform device\n");
return ret;
}
You can specify either RAM memory or peripheral devices’ memory. However, when specifying RAM, be sure to reserve the memory by issuing memblock_reserve() very early in the architecture code, e.g.:
You can specify RAM memory or peripheral device memory. However, if you specify RAM, issue memblock_reserve) very early in the architecture code to reserve memory.
#include <linux/memblock.h>
memblock_reserve(ramoops_data.mem_address, ramoops_data.mem_size);
Dump format
The data dump begins with a header, currently defined as ==== followed by a timestamp and a new line. The dump then continues with the actual data.
The data dump starts with a header defined as ===. Followed by a time stamp and a line break. Then dump is followed by the actual data.
Reading the data
The dump data can be read from the pstore filesystem. The format for these files is dmesg-ramoops-N, where N is the record number in memory. To delete a stored record from RAM, simply unlink the respective pstore file.
dump data can be read from the pstore filesystem. The format of this file is dmesg-ramoops-N. N is the recode number on memory. To remove the retained recode from RAM, simply delete the associated pstore file.
Persistent function tracing
Persistent function tracing might be useful for debugging software or hardware related hangs. The functions call chain log is stored in a ftrace-ramoops file. Here is an example of usage:
The persistent function tracing is useful for debugging software and hardware related to hang. The functions call chain log is recorded in the ftrace-ramoops file. Here is an example.
# mount -t debugfs debugfs /sys/kernel/debug/
# echo 1 > /sys/kernel/debug/pstore/record_ftrace
# reboot -f
[...]
# mount -t pstore pstore /mnt/
# tail /mnt/ftrace-ramoops
0 ffffffff8101ea64 ffffffff8101bcda native_apic_mem_read <- disconnect_bsp_APIC+0x6a/0xc0
0 ffffffff8101ea44 ffffffff8101bcf6 native_apic_mem_write <- disconnect_bsp_APIC+0x86/0xc0
0 ffffffff81020084 ffffffff8101a4b5 hpet_disable <- native_machine_shutdown+0x75/0x90
0 ffffffff81005f94 ffffffff8101a4bb iommu_shutdown_noop <- native_machine_shutdown+0x7b/0x90
0 ffffffff8101a6a1 ffffffff8101a437 native_machine_emergency_restart <- native_machine_restart+0x37/0x40
0 ffffffff811f9876 ffffffff8101a73a acpi_reboot <- native_machine_emergency_restart+0xaa/0x1e0
0 ffffffff8101a514 ffffffff8101a772 mach_reboot_fixups <- native_machine_emergency_restart+0xe2/0x1e0
0 ffffffff811d9c54 ffffffff8101a7a0 __const_udelay <- native_machine_emergency_restart+0x110/0x1e0
0 ffffffff811d9c34 ffffffff811d9c80 __delay <- __const_udelay+0x30/0x40
0 ffffffff811d9d14 ffffffff811d9c3f delay_tsc <- __delay+0xf/0x20
Originally, it is a part of the Linux Kernel source code, so it will be treated as GPLv2 (recognition that it should be).
https://www.kernel.org/doc/html/latest/index.html
Licensing documentation
The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.
https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing
Recommended Posts