Revision 5885b9b3f030f9b430f6b1c7fa396c885033f2f8 authored by Linus Torvalds on 16 December 2011, 19:14:42 UTC, committed by Linus Torvalds on 16 December 2011, 19:14:42 UTC
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: HDA: Use LPIB Position fix for Intel SCH Poulsbo ALSA: hda: fix mute led polarity for HP laptops with buggy BIOS ALSA: HDA: Set position fix to LPIB for an Atom/Poulsbo based device ASoC: Fix hx4700 error handling to free gpios if snd_soc_register_card fails ASoC: WM8958: correctly show firmware magic on mismatch ASoC: mxs: Add appropriate MODULE_ALIAS() ASoC: mxs: Add missing MODULE_LICENSE("GPL") ASoC: Fix WM8996 24.576MHz clock operation ASoC: Include linux/module.h for smdk2443_wm9710 ASoC: Fix a typo in jive_wm8750 ASoC: Fix build dependency for SND_SOC_JZ4740_CODEC ASoC: Include linux/io.h for jz4740 codec
ramoops.txt
Ramoops oops/panic logger
=========================
Sergiu Iordache <sergiu@chromium.org>
Updated: 8 August 2011
0. 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.
1. Ramoops concepts
Ramoops uses a predefined memory area to store the dump. The start and size of
the memory area are set using two variables:
* "mem_address" for the start
* "mem_size" for the size. The memory size will be rounded down to a
power of two.
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).
2. Setting the parameters
Setting the ramoops parameters can be done in 2 different manners:
1. Use the module parameters (which have the names of the variables described
as before).
2. 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:
#include <linux/ramoops.h>
[...]
static struct ramoops_platform_data ramoops_data = {
.mem_size = <...>,
.mem_address = <...>,
.record_size = <...>,
.dump_oops = <...>,
};
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;
}
3. 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.
4. Reading the data
The dump data can be read from memory (through /dev/mem or other means).
Getting the module parameters, which are needed in order to parse the data, can
be done through /sys/module/ramoops/parameters/* .
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...