diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2016-12-12 21:58:13 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2016-12-12 21:58:13 -0800 |
commit | e7aa8c2eb11ba69b1b69099c3c7bd6be3087b0ba (patch) | |
tree | f63906f41699c8e38af9d12b063e2ceab0286ef2 /Documentation/admin-guide/ramoops.rst | |
parent | e34bac726d27056081d0250c0e173e4b155aa340 (diff) | |
parent | 868c97a846a73e937d835b09b8c885a69df50ec8 (diff) | |
download | op-kernel-dev-e7aa8c2eb11ba69b1b69099c3c7bd6be3087b0ba.zip op-kernel-dev-e7aa8c2eb11ba69b1b69099c3c7bd6be3087b0ba.tar.gz |
Merge tag 'docs-4.10' of git://git.lwn.net/linux
Pull documentation update from Jonathan Corbet:
"These are the documentation changes for 4.10.
It's another busy cycle for the docs tree, as the sphinx conversion
continues. Highlights include:
- Further work on PDF output, which remains a bit of a pain but
should be more solid now.
- Five more DocBook template files converted to Sphinx. Only 27 to
go... Lots of plain-text files have also been converted and
integrated.
- Images in binary formats have been replaced with more
source-friendly versions.
- Various bits of organizational work, including the renaming of
various files discussed at the kernel summit.
- New documentation for the device_link mechanism.
... and, of course, lots of typo fixes and small updates"
* tag 'docs-4.10' of git://git.lwn.net/linux: (193 commits)
dma-buf: Extract dma-buf.rst
Update Documentation/00-INDEX
docs: 00-INDEX: document directories/files with no docs
docs: 00-INDEX: remove non-existing entries
docs: 00-INDEX: add missing entries for documentation files/dirs
docs: 00-INDEX: consolidate process/ and admin-guide/ description
scripts: add a script to check if Documentation/00-INDEX is sane
Docs: change sh -> awk in REPORTING-BUGS
Documentation/core-api/device_link: Add initial documentation
core-api: remove an unexpected unident
ppc/idle: Add documentation for powersave=off
Doc: Correct typo, "Introdution" => "Introduction"
Documentation/atomic_ops.txt: convert to ReST markup
Documentation/local_ops.txt: convert to ReST markup
Documentation/assoc_array.txt: convert to ReST markup
docs-rst: parse-headers.pl: cleanup the documentation
docs-rst: fix media cleandocs target
docs-rst: media/Makefile: reorganize the rules
docs-rst: media: build SVG from graphviz files
docs-rst: replace bayer.png by a SVG image
...
Diffstat (limited to 'Documentation/admin-guide/ramoops.rst')
-rw-r--r-- | Documentation/admin-guide/ramoops.rst | 156 |
1 files changed, 156 insertions, 0 deletions
diff --git a/Documentation/admin-guide/ramoops.rst b/Documentation/admin-guide/ramoops.rst new file mode 100644 index 0000000..4efd7ce --- /dev/null +++ b/Documentation/admin-guide/ramoops.rst @@ -0,0 +1,156 @@ +Ramoops oops/panic logger +========================= + +Sergiu Iordache <sergiu@chromium.org> + +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 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: + + * ``mem_address`` for the start + * ``mem_size`` for the size. The memory size will be rounded down to a + power of two. + * ``mem_type`` to specifiy if the 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 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. + +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. + +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). + +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. + +Setting the parameters +---------------------- + +Setting the ramoops parameters can be done in several different manners: + + 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:: + + mem=128M ramoops.mem_address=0x8000000 ramoops.ecc=1 + + B. Use Device Tree bindings, as described in + ``Documentation/device-tree/bindings/reserved-memory/admin-guide/ramoops.rst``. + 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: + + .. code-block:: c + + #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.:: + + #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. + +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. + +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:: + + # 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 |