char drivers: Ram oops/panic logger
in [Kernel]
|
Prev: [PATCH] Staging: asus_oled: Remove space character mixed in with tab indentation.
Next: madness, was Re: [PATCH 2/2] Macintosh: fix coding style issues in adb.c This is a patch to the adb.c file that cleans up many warnings found by the checkpatch.pl tool
From: Yuasa Yoichi on 9 Mar 2010 21:10 Hi, 2010/3/10 Marco Stornelli <marco.stornelli(a)gmail.com>: > Ramoops, like mtdoops, can log oops/panic information but in RAM. What is different from mtdoops + mtd-ram? Yoichi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Marco Stornelli on 10 Mar 2010 03:10 2010/3/10 Yuasa Yoichi <yuasa(a)linux-mips.org>: > Hi, > > 2010/3/10 Marco Stornelli <marco.stornelli(a)gmail.com>: >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yuasa Yoichi on 10 Mar 2010 04:30 2010/3/10 Marco Stornelli <marco.stornelli(a)gmail.com>: > 2010/3/10 Yuasa Yoichi <yuasa(a)linux-mips.org>: >> Hi, >> >> 2010/3/10 Marco Stornelli <marco.stornelli(a)gmail.com>: >>> 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. right. But, > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Marco Stornelli on 10 Mar 2010 07:20 2010/3/10 Yuasa Yoichi <yuasa(a)linux-mips.org>: > 2010/3/10 Marco Stornelli <marco.stornelli(a)gmail.com>: >> 2010/3/10 Yuasa Yoichi <yuasa(a)linux-mips.org>: >>> Hi, >>> >>> 2010/3/10 Marco Stornelli <marco.stornelli(a)gmail.com>: >>>> 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. > > right. > But, > >> 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. > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 12 Mar 2010 17:50
On Wed, 10 Mar 2010 13:15:25 +0100 Marco Stornelli <marco.stornelli(a)gmail.com> wrote: > 2010/3/10 Yuasa Yoichi <yuasa(a)linux-mips.org>: > > 2010/3/10 Marco Stornelli <marco.stornelli(a)gmail.com>: > >> 2010/3/10 Yuasa Yoichi <yuasa(a)linux-mips.org>: > >>> Hi, > >>> > >>> 2010/3/10 Marco Stornelli <marco.stornelli(a)gmail.com>: > >>>> 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. > > > > right. > > But, > > > >> 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. > > > > 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. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |