From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marco Stornelli <marco.stornelli@gmail.com>
Subject: Re: [PATCH v2] char drivers: Ram oops/panic logger
Date: Sat, 13 Mar 2010 09:50:07 +0100
Message-ID: <4B9B51BF.2070201@gmail.com>
References: <4B968834.3040609@gmail.com>	<21eaeb5a1003091808s2d7638cxd524952a7d84b378@mail.gmail.com>	<2ea1731b1003100002w104633ffy1ae46ef3d245e5b5@mail.gmail.com>	<21eaeb5a1003100120x6cd3f69ak598954af3c9fe955@mail.gmail.com>	<2ea1731b1003100415i46dd8fcem85b85f49fb1a479@mail.gmail.com> <20100312144854.cb94d9b4.akpm@linux-foundation.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <linux-embedded-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from
         :user-agent:mime-version:to:cc:subject:references:in-reply-to
         :content-type:content-transfer-encoding;
        bh=jnJGm8QE/l0JcUv9pegcBr+BJuhB6j2BCfDCCdvWI4s=;
        b=qSrfc3WDghYKiUdq8ojIP9bnJE1ZhVS77vJB/hZwH3dSE84WTD0yYfyFeUcWMCv9Ip
         /L+f3/TUuNQctHwZslYgqEkaJ+1mVbNDkDGLlqw45Coy2N3+NR70wLvcM0Ff6Ppsm7Vi
         eKxAefgXSKOrLwU88vm7ToD5JofCpMWHGgdJA=
In-Reply-To: <20100312144854.cb94d9b4.akpm@linux-foundation.org>
Sender: linux-embedded-owner@vger.kernel.org
List-ID: <linux-embedded.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Yuasa Yoichi <yuasa@linux-mips.org>, Linux Kernel <linux-kernel@vger.kernel.org>, Linux Embedded <linux-embedded@vger.kernel.org>, jamie@shareable.org

Il 12/03/2010 23:48, Andrew Morton ha scritto:
> On Wed, 10 Mar 2010 13:15:25 +0100
> Marco Stornelli <marco.stornelli@gmail.com> wrote:
> 
>> 2010/3/10 Yuasa Yoichi <yuasa@linux-mips.org>:
>>> 2010/3/10 Marco Stornelli <marco.stornelli@gmail.com>:
>>>> 2010/3/10 Yuasa Yoichi <yuasa@linux-mips.org>:
>> 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?

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?

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.

> 
> 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