lkml.org 
[lkml]   [2012]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/5] Persist printk buffer across reboots.
    On 3/12/2012 10:36 PM, Avery Pennarun wrote:
    > The last patch in this series implements a new CONFIG_PRINTK_PERSIST option
    > that, when enabled, puts the printk buffer in a well-defined memory location
    > so that we can keep appending to it after a reboot. The upshot is that,
    > even after a kernel panic or non-panic hard lockup, on the next boot
    > userspace will be able to grab the kernel messages leading up to it. It
    > could then upload the messages to a server (for example) to keep crash
    > statistics.
    >
    > The preceding patches in the series are mostly just things I fixed up while
    > working on that patch.
    >
    > Some notes:
    >
    > - I'm not totally sure of the locking or portability issues when calling
    > memblock or bootmem. This all happens really early, and I *think*
    > interrupts are still disabled at that time, so it's probably okay.
    >
    > - Tested this version on x86 (kvm) and it works with soft reboot (ie. reboot
    > -f). Since some BIOSes wipe the memory during boot, you might not have
    > any luck. It should be great on many embedded systems, though, including
    > the MIPS system I've tested a variant of this patch on. (Our MIPS build
    > is based on a slightly older kernel so it's not 100% the same, but I think
    > this should behave identically.)
    >
    > - The way we choose a well-defined memory location is slightly suspicious
    > (we just count down from the top of the address space) but I've tested it
    > pretty carefully, and it seems to be okay.
    >
    > - In printk.c with CONFIG_PRINTK_PERSIST set, we're #defining words like
    > log_end. It might be cleaner to replace all instances of log_end with
    > LOG_END to make this more clear. This is also the reason the struct
    > logbits members start with _: because otherwise they conflict with the
    > macro. Suggestions welcome.

    Android has something similar called ram_console (see
    staging/android/ram_console.c). The console is dumped to a ram buffer
    that is reserved very early in platform setup code. Then when the phone
    reboots you can cat /proc/last_kmsg to get the previous kernel message
    for debugging. Can you use that code?

    --
    Sent by an employee of the Qualcomm Innovation Center, Inc.
    The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.



    \
     
     \ /
      Last update: 2012-03-13 09:35    [W:0.025 / U:0.132 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site