[Ce-android-mainline] ram console

Colin Cross ccross at android.com
Thu Jan 19 19:20:06 UTC 2012


On Thu, Jan 19, 2012 at 11:00 AM, Tim Bird <tim.bird at am.sony.com> wrote:
> Thanks very much for the response, Todd.  This is very helpful.
>
> On 01/19/2012 10:02 AM, Todd Poynor wrote:
>> Patches have also been floated that generalize ramconsole to a
>> persistent memory area that also stores general < key, value > pairs
>> set by the the previous boot of the kernel for debugging specific
>> problems.
>
> I'm curious what type of information it would make sense to
> make a separate interface for, rather than just using printks
> for these.  Is this just to simplify parsing after the fact,
> or would there be some kind of extraction/filtering API as well?
> Do you have an example of the type of data that would be
> saved this way?

The patches Todd referred to refactor the persistent storage out of
the ramconsole driver itself, so that the persistent storage can be
used by other tools.  The two uses we have for this so far are both
for development only.

One is persistent variables, which allows storing a write-many
variable in a hot path (too hot for a printk), and then seeing what
the last value was after a reboot.  I mostly used this for debugging
problems in low power idle, storing information on the next idle state
before entering idle, and then reading back after a HW freeze and
watchdog reset.  I don't expect this to be upstreamable in its current
form.

The second (and far more useful) tool is a persistent ftrace.  It can
log pc and lr for every function call, and after a reboot it will dump
the call trace that led to the reboot through /proc/persistent_trace.
It is extremely useful to debug watchdog resets, because you can see
what each cpu was doing that led up to the hang.

> Also, have you considered putting the logs into this kind of
> persistent buffer?  I think Brian mentioned something about
> a feature to make the logger buffers persistent.

Yes, we would also like to put the android logger on top of
persistent_ram as well, but that hasn't been done yet.


More information about the Ce-android-mainline mailing list