Re: Kernel crashing and log buffers...

[Robin Getz <rgetz@blackfin.uclinux.org>]

On Fri 26 Jun 2009 13:42, David VomLehn pondered:
> On Fri, Jun 26, 2009 at 10:39:50AM -0400, Robin Getz wrote:
> > OK - so after a bit more digging into things (and a poke by Mike) - I
> think 
> > most of the stuff already exists.
> > 
> > Normal run time issues:
> > --------------------------
> >  - MTD_OOPS - on 2007-06-28 this was added to Linus's tree:
> >     http://lkml.org/lkml/2007/6/18/234
> >     CONFIG_MTD_OOPS
> >       tristate "Log panic/oops to an MTD buffer"
> ...
> > early boot issues:
> > ----------------------
> >  - CONFIG_EARLY_PRINTK
> >    - early printk just defined a console - and is supported by:
> >       alpha, blackfin, microblaze, mips, powerpc, sh, x86
> >    - it's pretty trivial to support a memory based buffer - some
> >      archs already support it.
> > 
> > I think this only leaves Wolfgang's desire for memory buffers from the
> 
> > bootloader to get (somehow) into the kernel's log buffer for syslog 
> > processing...
> > 
> > Anyone else agree?
> 
> Almost. A couple of us also want memory for "flight data record" FDR
> data for doing continuous logging. This would, ideally, be either uncached
> or cached in such a way that data is guaranteed to be written to memory in
> the event of a watchdog timer-induced system reset.

Many of the early_printk implementations accept a "keep" option (which does 
not remove the console/buffer - and keeps it around forever) - I'm adding 
that to the Blackfin implementation as we speak - but it is already there on 
sh.

I expect that we could add something to the MTD_OOPS, as to allways write as 
well (console=ttyMTDx,log_level) or something like that if the backing needed 
to be flash.

Would that satisfy things?

-Robin