char drivers: Ram oops/panic logger
PATCH v2 1/1 char drivers: Ram oops/panic logger
Ramoops, like mtdoops, can log oops/panic information but in RAM. It can be used with persistent RAM for systems without flash support. In addition, for this systems, with this driver, it's no more needed add to the kernel the mtd subsystem with advantage in footprint.
---
drivers/char/Kconfig +7 -0
@@ -1105,5 +1105,12 @@ config DEVPORT source "drivers/s390/char/Kconfig" +config RAMOOPS + tristate "Log panic/oops to a RAM buffer" + default n + help + This enables panic and oops messages to be logged to a circular + buffer in RAM where it can be read back at some later point. + endmenu
drivers/char/Makefile +1 -0
@@ -107,6 +107,7 @@ obj-$(CONFIG_HANGCHECK_TIMER) += hangche obj-$(CONFIG_TCG_TPM) += tpm/ obj-$(CONFIG_PS3_FLASH) += ps3flash.o +obj-$(CONFIG_RAMOOPS) += ramoops.o obj-$(CONFIG_JS_RTC) += js-rtc.o js-rtc-y = rtc.o
drivers/char/ramoops.c +162 -0
162 lines not on this page · raw message
Hi,
2010/3/10 Marco Stornelli <[email protected]>:
Quoted 1 line
Ramoops, like mtdoops, can log oops/panic information but in RAM.
What is different from mtdoops + mtd-ram?
Yoichi
2010/3/10 Yuasa Yoichi <[email protected]>:
Quoted 9 lines
Hi,
2010/3/10 Marco Stornelli <[email protected]>:
Quoted 1 line
Ramoops, like mtdoops, can log oops/panic information but in RAM.
What is different from mtdoops + mtd-ram?
Yoichi
It can be used in a very easy way with persistent RAM for systems without flash support. For this systems, with this driver, it's no more needed add to the kernel the mtd subsystem with advantage in footprint as I said in the description. In addition, you can save flash space and store this information only in RAM. I think it's very useful for embedded systems.
Marco
2010/3/10 Marco Stornelli <[email protected]>:
Quoted 8 lines
2010/3/10 Yuasa Yoichi <[email protected]>:
Quoted 7 lines
Hi,
2010/3/10 Marco Stornelli <[email protected]>:
Quoted 1 line
Ramoops, like mtdoops, can log oops/panic information but in RAM.
What is different from mtdoops + mtd-ram?
Quoted 7 lines
Quoted 2 lines
Yoichi
It can be used in a very easy way with persistent RAM for systems without flash support. For this systems, with this driver, it's no more needed add to the kernel the mtd subsystem with advantage in footprint as I said in the description.
right.
But,
Quoted 3 lines
In addition, you can save
flash space and store this information only in RAM. I think it's very useful for embedded systems.
CONFIG_MTD_RAM uses only RAM.
I think there's no big difference about this point.
Yoichi
2010/3/10 Yuasa Yoichi <[email protected]>:
Quoted 20 lines
2010/3/10 Marco Stornelli <[email protected]>:
Quoted 8 lines
2010/3/10 Yuasa Yoichi <[email protected]>:
Quoted 7 lines
Hi,
2010/3/10 Marco Stornelli <[email protected]>:
Quoted 1 line
Ramoops, like mtdoops, can log oops/panic information but in RAM.
What is different from mtdoops + mtd-ram?
Quoted 7 lines
Quoted 2 lines
Yoichi
It can be used in a very easy way with persistent RAM for systems without flash support. For this systems, with this driver, it's no more needed add to the kernel the mtd subsystem with advantage in footprint as I said in the description.
right.
But,
Quoted 7 lines
Quoted 3 lines
In addition, you can save
flash space and store this information only in RAM. I think it's very useful for embedded systems.
CONFIG_MTD_RAMuses only RAM.
I think there's no big difference about this point.
I meant with the "classic" use of mtdoops, therefore with a flash partition without use MTD_RAM. Using MTD_RAM, it's more or less the same thing, with the exception of "where" you want deploy the log. For
example: if in your system you have got a nvram you can use it without problem, you need to specify the address of the nvram to the module. Very simple. I think it's a small driver but very useful, feedback from other embedded guys are welcome.
Marco
Quoted 29 lines · On Wed, 10 Mar 2010 13:15:25 +0100 Marco Stornelli <[email protected]>…
2010/3/10 Yuasa Yoichi <[email protected]>:
Quoted 20 lines
2010/3/10 Marco Stornelli <[email protected]>:
Quoted 8 lines
2010/3/10 Yuasa Yoichi <[email protected]>:
Quoted 7 lines
Hi,
2010/3/10 Marco Stornelli <[email protected]>:
Quoted 1 line
Ramoops, like mtdoops, can log oops/panic information but in RAM.
What is different from mtdoops + mtd-ram?
Quoted 7 lines
Quoted 2 lines
Yoichi
It can be used in a very easy way with persistent RAM for systems without flash support. For this systems, with this driver, it's no more needed add to the kernel the mtd subsystem with advantage in footprint as I said in the description.
right.
But,Quoted 7 lines
Quoted 3 lines
In addition, you can save
flash space and store this information only in RAM. I think it's very useful for embedded systems.
CONFIG_MTD_RAMuses only RAM.
I think there's no big difference about this point.
Quoted 7 lines
I meant with the "classic" use of mtdoops, therefore with a flash partition without use
MTD_RAM. UsingMTD_RAM, it's more or less the same thing, with the exception of "where" you want deploy the log. For
example: if in your system you have got a nvram you can use it without problem, you need to specify the address of the nvram to the module. Very simple. I think it's a small driver but very useful, feedback from other embedded guys are welcome.
Seems sensible to me. If you have a machine whose memory is persistent across reboots then you reserve an arbitrary 4k hunk of memory for collecting oops traces, yes?
What tools are used for displaying that memory on the next boot? How do those tools distinguish between "valid oops trace" and "garbage because it was just powered on"? A magic signature?
Should the kernel provide the 4k of memory rather than (or in addition to) requiring that the system administrator reserve it and tell the kernel about it? That'd be a matter of creating a linker section which isn't cleared out by the startup code.
Quoted 11 lines · Andrew Morton
Quoted 7 lines
I meant with the "classic" use of mtdoops, therefore with a flash partition without use
MTD_RAM. UsingMTD_RAM, it's more or less the same thing, with the exception of "where" you want deploy the log. For
example: if in your system you have got a nvram you can use it without problem, you need to specify the address of the nvram to the module. Very simple. I think it's a small driver but very useful, feedback from other embedded guys are welcome.Seems sensible to me. If you have a machine whose memory is persistent across reboots then you reserve an arbitrary 4k hunk of memory for collecting oops traces, yes?
Me too, I think it's a great idea which sounds simpler to use than MTD-RAM.
Quoted 8 lines
What tools are used for displaying that memory on the next boot? How do those tools distinguish between "valid oops trace" and "garbage because it was just powered on"? A magic signature?
Should the kernel provide the 4k of memory rather than (or in addition to) requiring that the system administrator reserve it and tell the kernel about it? That'd be a matter of creating a linker section which isn't cleared out by the startup code.
It's good if there's an option to make the location not vary between kernels, and be known to the bootloader.
Then you can debug kernels which always crash during boot, by either booting into another kernel which works and looking at the oops, or by a bootloader command to dump it.
That'd be fine if the kernel link scripts choose the address, as long as it's consistent between different compiles and similar configurations. That'd be a bit simpler than the admin having to know the memory map well enough to choose an address.
-- Jamie
Il 13/03/2010 00:31, Jamie Lokier ha scritto:
Quoted 7 lines
That'd be fine if the kernel link scripts choose the address, as long as it's consistent between different compiles and similar configurations. That'd be a bit simpler than the admin having to know the memory map well enough to choose an address.
-- Jamie
I agree, but the bootloader should be aware of it. I mean, usually bootloaders at boot, reset the RAM, so you have to tell to the bootloader that you are using a piece of RAM as persistent RAM, for example U-Boot has got a specific option CONFIG_PRAM. I don't know if all the process can be completely transparent to the admin in all situations.
Marco
Quoted 9 lines · Marco Stornelli
Il 13/03/2010 00:31, Jamie Lokier ha scritto:
Quoted 7 lines
That'd be fine if the kernel link scripts choose the address, as long as it's consistent between different compiles and similar configurations. That'd be a bit simpler than the admin having to know the memory map well enough to choose an address.
-- Jamie
Quoted 6 lines
I agree, but the bootloader should be aware of it. I mean, usually bootloaders at boot, reset the RAM, so you have to tell to the bootloader that you are using a piece of RAM as persistent RAM, for example U-Boot has got a specific option
CONFIG_PRAM. I don't know if all the process can be completely transparent to the admin in all situations.
Sometimes you can't change the bootloader (they don't always come with source code). Or you could, but you don't want to risk it (there isn't always a way to recover if you break it).
Obviously then the feature is only useful when the bootloader doesn't clear all the RAM :-)
On slow boards in consumer devices, they sometimes avoid clearing the RAM because that adds measurable boot time.
-- Jamie
2010/3/15 Jamie Lokier <[email protected]>:
Quoted 13 lines
Quoted 7 lines · Marco Stornelli
Il 13/03/2010 00:31, Jamie Lokier ha scritto:
I agree, but the bootloader should be aware of it. I mean, usually bootloaders at boot, reset the RAM, so you have to tell to the bootloader that you are using a piece of RAM as persistent RAM, for example U-Boot has got a specific optionCONFIG_PRAM. I don't know if all the process can be completely transparent to the admin in all situations.Sometimes you can't change the bootloader (they don't always come with source code). Or you could, but you don't want to risk it (there isn't always a way to recover if you break it).
Quoted 6 lines
Obviously then the feature is only useful when the bootloader doesn't clear all the RAM :-)
On slow boards in consumer devices, they sometimes avoid clearing the RAM because that adds measurable boot time.
In the embedded world, usually, you can change/write the fw and you know well the memory map, so no problem to know the address to use. In other cases, it can be possible to use a "transparent" approach, but in my opinion the general approach used by the driver is enough.
Marco
Il 12/03/2010 23:48, Andrew Morton ha scritto:
Quoted 14 lines
Quoted 10 lines · On Wed, 10 Mar 2010 13:15:25 +0100 Marco Stornelli <[email protected]>…
2010/3/10 Yuasa Yoichi <[email protected]>:
Quoted 2 lines
2010/3/10 Marco Stornelli <[email protected]>:
Quoted 1 line
2010/3/10 Yuasa Yoichi <[email protected]>:
I meant with the "classic" use of mtdoops, therefore with a flash partition without use
MTD_RAM. UsingMTD_RAM, it's more or less the same thing, with the exception of "where" you want deploy the log. For
example: if in your system you have got a nvram you can use it without problem, you need to specify the address of the nvram to the module. Very simple. I think it's a small driver but very useful, feedback from other embedded guys are welcome.
Quoted 3 lines
Seems sensible to me. If you have a machine whose memory is persistent across reboots then you reserve an arbitrary 4k hunk of memory for collecting oops traces, yes?
Yes.
Quoted 4 lines
What tools are used for displaying that memory on the next boot? How do those tools distinguish between "valid oops trace" and "garbage because it was just powered on"? A magic signature?
For my test I used the program devmem2 to dump the log. In general, you can read the memory via /dev/mem. There's an header plus a timestamp of the log. The memory is initialized with blank spaces and the size of the record is fixed at 4k, so if a program/script doesn't find the header at next 4k, it means there's garbage and it can stop the read operation.
Quoted 7 lines
Should the kernel provide the 4k of memory rather than (or in addition to) requiring that the system administrator reserve it and tell the kernel about it? That'd be a matter of creating a linker section which isn't cleared out by the startup code.
Yes, it can be an option. My first idea was to write a "general" driver, with an address in input that it can be related to the reserved RAM as an NVRAM in the system, however it can be a good idea, why not.
Marco
Quoted 40 lines · Andrew Morton
Quoted 29 lines · On Wed, 10 Mar 2010 13:15:25 +0100 Marco Stornelli <[email protected]>…
2010/3/10 Yuasa Yoichi <[email protected]>:
Quoted 20 lines
2010/3/10 Marco Stornelli <[email protected]>:
Quoted 8 lines
2010/3/10 Yuasa Yoichi <[email protected]>:
Quoted 7 lines
Hi,
2010/3/10 Marco Stornelli <[email protected]>:
Quoted 1 line
Ramoops, like mtdoops, can log oops/panic information but in RAM.
What is different from mtdoops + mtd-ram?
Quoted 7 lines
Quoted 2 lines
Yoichi
It can be used in a very easy way with persistent RAM for systems without flash support. For this systems, with this driver, it's no more needed add to the kernel the mtd subsystem with advantage in footprint as I said in the description.
right.
But,Quoted 7 lines
Quoted 3 lines
In addition, you can save
flash space and store this information only in RAM. I think it's very useful for embedded systems.
CONFIG_MTD_RAMuses only RAM.
I think there's no big difference about this point.Quoted 7 lines
I meant with the "classic" use of mtdoops, therefore with a flash partition without use
MTD_RAM. UsingMTD_RAM, it's more or less the same thing, with the exception of "where" you want deploy the log. For
example: if in your system you have got a nvram you can use it without problem, you need to specify the address of the nvram to the module. Very simple. I think it's a small driver but very useful, feedback from other embedded guys are welcome.
Quoted 7 lines
Seems sensible to me. If you have a machine whose memory is persistent across reboots then you reserve an arbitrary 4k hunk of memory for collecting oops traces, yes?
What tools are used for displaying that memory on the next boot? How do those tools distinguish between "valid oops trace" and "garbage because it was just powered on"? A magic signature?
On Amiga, `debug=mem' enables something like that, cfr. git grep dmesg arch/m68k.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds