[Ksummit-2012-discuss] [ATTEND] kernel core dump and "dying breath"
roland at kernel.org
Sat Jun 23 02:00:27 UTC 2012
On Thu, Jun 21, 2012 at 10:20 AM, Tim Bird <tim.bird at am.sony.com> wrote:
> I think the persistent RAM stuff that is in the process of being
> migrated from Android's ram_console feature into ramoops and pstore
> might be just what you are looking for. This reserves a area of RAM
> that can be read by the kernel after rebooting, and optionally adds
> some error correction for bits which might flip over the reboot.
> I believe the goal is to generalize this for use with other items
> besides the log buffer.
As others have mentioned, this probably doesn't work on any x86
platforms, since the BIOS typically clear memory on a reboot.
But I think it's useful to distinguish two related topics being
discussed in this thread -- first, we want a mechanism to get
data out of a system at crash time; this includes pstore with
ERST/EFI vars/whatever, cool QR hacks, etc. Second, we
want to be able to choose what data to capture -- oops/stack
trace, ftrace buffer, etc.
The first has been an interesting topic for me -- as I've mentioned
before, we're delivering an appliance on pretty standard westmere
server hardware, and we happen to have neither ERST nor EFI,
so pstore doesn't work for us. I've actually implemented a cute
hack to let a partner system (we deliver HA pairs) grab crash data
via RDMA over InfiniBand -- I need to clean that up and post it.
But it would be really nice if Intel could architect a solution for
saving some crash dump that was part of the guaranteed platform,
so we didn't have to rely on FW vendors building ERST support
or booting via EFI or whatever. I know that message has been
given to the architects many times, and it's not an easy problem,
so perhaps not relevant to KS discussion.
As far as the second issue is concerned -- I've hooked into
kmsg_dump_register() just like pstore etc. so right now I really
only get the kernel log buffer. I can set ftrace_dump_on_oops
to get ftrace, and so on, but perhaps having a way to configure
what information is of interest at crash time that is factored out
of all the ways of saving that information is a good idea.
More information about the Ksummit-2012-discuss