lkml.org 
[lkml]   [2009]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: RFC: Put printk buffer in video ram
    From
    Date
    On Sun, 2009-11-22 at 14:15 +0200, Maxim Levitsky wrote: 
    > On Sun, 2009-11-22 at 09:25 +0100, Ingo Molnar wrote:
    > > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
    > >
    > > > On Sun, Nov 22, 2009 at 04:05:06AM +0200, Maxim Levitsky wrote:
    > > > > After doing some successful debugging by placing printk buffer in video
    > > > > ram, here I publish cleaned version of it.
    > > > >
    > > > > I discovered that on my system video ram isn't cleared on reboot, and I
    > > > > took advantage of that by placing printk buffer directly there.
    > > > > This allows to capture oopses/panicks almost from everywhere.
    > > > > It is also very simple to setup.

    Few more thoughts:

    First of all, if I implement this as a console driver, I won't be able
    to capture all kernel log, but only from the point I register the
    console.
    My implementation, also isn't set up very early, but I copy already
    written log to the memory buffer.

    Problem of automatic unregistration isn't a problem, its just a feature,
    I could skip using.

    Secondary, I found out that system ram isn't cleared ether on my
    notebook, however I found out that I can't reserve small memory range
    with 'memmap' kernel parameter. System just panics.
    I used for reference 'memmap=2M$0x60000000'
    My system has 2GB of memory.

    I could reserve the memory same way using the code, but it would
    probably fail in same way. Also I could try early reservations, but I am
    not sure I can reserve _any_ address range. I test this.

    I think that patches to put printk buffer at predefined area in system
    ram were once posted on LKML.



    And now, to be honest, lets talk about existing solutions:

    1 - kdump/kexec - not a bad thing, but it has some disadvantages, namely
    I need to compile seperate kernel, there is a probility of new kernel
    not booting up (in fact I once installed kexec-tools, and it made system
    reboot using kexec, and I remember a hang because of that...)
    However, this approach doesn't need any 'help' from BIOS.

    2 - mtdoops + phram - There is a console driver that logs into mtd
    device. I don't know how it selects one.
    It is possible to create a 'fake' mtd device that will span a range in
    physical memory.
    I couldn't make this work, it has problems with early output, etc..


    Best regards,
    Maxim Levitsky



    \
     
     \ /
      Last update: 2009-11-23 02:05    [W:0.027 / U:0.088 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site