[Ksummit-2012-discuss] [ATTEND] kernel core dump and "dying breath"
jason.wessel at windriver.com
Thu Jun 21 11:36:29 UTC 2012
On 06/21/2012 06:14 AM, James Bottomley wrote:
> So I think we're advocating something much more simplistic. The basic
> problem is that a lot of kernel crashes are very hard for the average
> user to report: for a lot the best we get is a photo of the crash
> screen with most of the relevant information scrolled off the top.
> Serial or net consoles may be standard dev tools, but they're also too
> complex for most average users (although, to their credit, there's a lot
> who try).
> So the question becomes could we make the gathering of this data easier,
> so it just becomes a cut and paste from a log file (or even an automatic
> submission depending on what permissions you gave your distro). The
> thought is that a lot of systems are coming with areas of NVRAM today,
> so we could write the dying gasp of a crashing kernel to this NVRAM area
> (avoids most of the problems that trying to write this to disk had and
> NVRAM isn't cleared on bios init) and then spit it out on next boot in a
> form that can be easily consumed by automated bug reporting tools or
> easily cut and pasted into an email.
I would absolutely love it if the hardware vendors included something
that we could consistently use for "dying breath information" for
automated reporting. On many deeply embedded systems we have long had
NVRAM and such, but issue has always been that every single board is
different. Once, to catch a crash a local engineer cooked up a patch
to write things out to video RAM with a checksum, and then collected
it back into a buffer at boot time prior to video init.
If something has changed here I am a strong advocate to make an ever
so slight change to the output crashes so we get the module section
data which we can then use to fully decode oops automatically into
lines for locations (for your automated reports). And this only needs
to be done for the "dying breath". I also believe it should be
configurable of course to easily obtain other things. For what ever
memory we have for the "save" area, I have no doubt we can make good
use of it.
More information about the Ksummit-2012-discuss