Saving the kernel log accross boots
Hi All
In case of a crash we would like to save the kernel log and retrieve it in
the next boot.
There are already several suggestions on how to do it on this and other
lists.
(Kernel crashing and log buffers: Robin Getz)
Unfortunately we don't have extra SRAM to use for it. We need to do it in
the 'normal' RAM.
ARCH=ARM
What we did:
- modify kernel/printk.c: use
__attribute__((__section__(".bss.kringbuf"... to put the log related stuf
into a separate section
- modify the linker script to link .bss.kringbuf at the start of the .bss
section
- modify arch/arm/kernel/head-common.S to exclude the new section from
being nulled (if it was a watchdog restart)
- modify kernel/printk.c to use cach_flush after prink
- make sure the bootloader does not overwrite that memory
This seems to work.
After a crash we get the messages from the new boot and the last crash.
It seems that the decompress code is using memory at the end of the kernel
and destroys the log. So we have to use the bootloader to decompress the
image into RAM.
Before digging any deeper I would like to know if someone as a better
(more general) idea.
Regards, Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Saving the kernel log accross boots
Martin Meuli wrote: > > Before digging any deeper I would like to know if someone as a better > (more general) idea. Could you stuff the output into an MTD device? What about netconsole, or putting the console on a serial port? Then you could send the log out before and up to the point the crash happens. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Saving the kernel log accross boots
> > Before digging any deeper I would like to know if someone as a better > > (more general) idea. > > Could you stuff the output into an MTD device? For that, see CONFIG_MTD_OOPS. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: Saving the kernel log accross boots
Martin Meuli wrote:
> Hi All
>
> In case of a crash we would like to save the kernel log and retrieve it
> in the next boot.
> There are already several suggestions on how to do it on this and other
> lists.
> (Kernel crashing and log buffers: Robin Getz)
> Unfortunately we don't have extra SRAM to use for it. We need to do it
> in the 'normal' RAM.
>
> ARCH=ARM
>
> What we did:
> - modify kernel/printk.c: use
> __attribute__((__section__(".bss.kringbuf"... to put the log related
> stuf into a separate section
> - modify the linker script to link .bss.kringbuf at the start of the
> .bss section
> - modify arch/arm/kernel/head-common.S to exclude the new section from
> being nulled (if it was a watchdog restart)
> - modify kernel/printk.c to use cach_flush after prink
> - make sure the bootloader does not overwrite that memory
>
> This seems to work.
> After a crash we get the messages from the new boot and the last crash.
> It seems that the decompress code is using memory at the end of the
> kernel and destroys the log. So we have to use the bootloader to
> decompress the image into RAM.
>
> Before digging any deeper I would like to know if someone as a better
> (more general) idea.
>
> Regards, Martin
I submitted for a review a new filesystem for 2.6.30 called pramfs that
it can be useful for your case. You could use a little piece of ram to
store the log.
Marco
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Saving the kernel log accross boots
On Thu, 25 Jun 2009 17:29:54 +0200, Wolfram Sang wrote: > Before digging any deeper I would like to know if someone as a better > (more general) idea. Could you stuff the output into an MTD device? For that, see CONFIG_MTD_OOPS. Thak's looks great. Right now we have a watchdog without OOPS. Regards, Wolfram -- MM -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
