Messages in this thread |  | | | Date | Tue, 23 Nov 2010 13:30:54 +0900 | | Subject | Re: [RFC] persistent store | | From | Kyungmin Park <> |
| |
On Tue, Nov 23, 2010 at 12:10 PM, Tony Luck <tony.luck@intel.com> wrote: > On Mon, Nov 22, 2010 at 5:37 PM, Tony Luck <tony.luck@intel.com> wrote: >> Yes - I assume here that the last "data_size" bytes will be enough >> to be useful. But in your case it most likely won't be. You could >> lie about how much space you allow and then include some oops >> parsing code to get the vital bits out of what is passed to you. Not >> pretty - but it would work. If there are many such devices with limited >> capacity, then it would make sense to include this parsing code >> in this generic layer. > > Sorry - finding the good bits from the console log is architecture > dependent ... so it can't be done (easily) in the generic code.
FYI:
Now we use ramoops for this purpose. Even tough ramoops uses volatile memory, it's safe soft-reset and watchdog reset. To overcome limiataion of ramoops. not persist, I'm working on mmcoops as persistent oops record.
As the discussed story. it covers the previous oops devices, mtdoops(drivers/mtd/mtdoops.c), ramoops (drivers/char/ramoops.c) and mmcoops (drivers/mmc/card/mmc_oops.c).
Actually I tried to enable the lcdoops, display oops message at LCD. but it doesn't work since not much time to display LCD.
Thank you, Kyungmin Park
> > -Tony > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |