[Ce-android-mainline] ram console

[Tim Bird]

On 01/18/2012 04:30 PM, Shuah Khan wrote:
> I have been investigating ramconsole and some of the ways it can be
> supported on mainline. My focus has been to look for existing features
> that could be used to support ramconsole as opposed to requesting ramconsole
> to be included in the mainline.
> 
> ram console registers a console to save printk messages to a designated
> area in RAM to be retrieved for diagnostics. Previous boot kernel messages
> can be retrieved from /proc/last_kmsg file. The main usage appears to be for
> panic debugs.
> 
> One alternative is to use pstore infrastructure to support ram console
> equivalent functionality. pstore uses kmsg_dump callback interface to get
> the last messages that are in the log buffer after a previous Read and Clear
> (SYSLOG_ACTION_READ_CLEAR). It appears SYSLOG_ACTION_READ_CLEAR is a rare
> operation used only by selinux_syslog(). So there is a good probability that
> the entire log since boot is preserved unless it rolls over. But there
> are no
> gaurantees, hence this route will not save what ram console would save.

Forgive my ignorance, but how is pstore activated?  ram console
will preserve messages up to the point of failure, since it saves
them at the time of the printk (submission to the log).  It sounds like
pstore is activated from a panic.  Is that right?

> 
> Another limitaion is that the log could keep moving after kmsg_dump
> callbacks
> are invoked. Hence pstore dump will not be as complete a ram console
> would be.

Does this happen very much in practice.  Where is pstore in the
panic sequence?  Is there much left that the machine does before
dying?

> 
> However pstore is extensible with more than one back-end and is in mainline.
> 
> ramoops driver also saves panic messages in pre-determined RAM location. It
> currently uses kmsg_dump callback to retrieve messages. There is a patch
> that
> has been sent to lkml a month ago that does the updates to ramoops to use
> pstore. However, it is not approved yet. One tact to take is to work towards
> getting that patch mainlined.
> 
> Reference: https://lkml.org/lkml/2011/12/3/24
> 
> By enabling CONFIG_RAMOOPS when CONFIG_ANDROID_RAM_CONSOLE is specified,
> the
> ram console feature can be supported without changes to Android
> userspace and
> platform code. Maybe SYSLOG_ACTION_READ_CLEAR could be disabled when
> CONFIG_ANDROID_RAM_CONSOLE is enabled to ensure entire log is saved.

Is this true.  What about /proc/last_kmsg?  How is that related to
/dev/pstore (or whereever the pstore filesystem shows up)?
Are extra mount operations required to access the pstore filesystem,
that are not required with in the /proc case.

Does pstore or ramoops have any error correction capability, like
ram console?  I presume this is to help ameliorate problems with RAM
degradation over a reboot, but does anyone know.  Is this turned
on by default for ram console in Android devices?  Is ram console
enabled on production devices, or only during development?
(I don't know if you know the answers to these, but it might
help understand the common Android use case if we can find out.)

> Couple of open issues I am looking into are the dependency pstore has on
> IOMEM and how that would play into using ramoops instead of ramconsole.
> 
> Please give me feedback.

What is the status of ram console in mainline?  It looks like it's in
driver/staging/android.

Have you, or anyone else, brought up these issues on LKML for advice?
If you do, please copy me so I can follow the discussion.  Make sure
to copy Tony Luck as the pstore maintainer.

Personally, I prefer the ram console approach to saving messages,
as it more closely matches what how the serial console works,
and also saves messages in cases where the kernel doesn't even
panic correctly (though these are probably rare).

 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================