From: Frederic Weisbecker <fweisbec@gmail.com>
To: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: RFC: Put printk buffer in video ram
Date: Sun, 22 Nov 2009 03:32:39 +0100 [thread overview]
Message-ID: <20091122023237.GA6572@nowhere> (raw)
In-Reply-To: <1258855506.3153.1.camel@maxim-laptop>
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.
>
>
> Best regards,
> Maxim Levitsky
>
> ---
>
> >From 77e0f4ffc531417d54ce928ade8481d82192b012 Mon Sep 17 00:00:00 2001
> From: Maxim Levitsky <maximlevitsky@gmail.com>
> Date: Sun, 22 Nov 2009 03:49:04 +0200
> Subject: [PATCH] printk: Allow to store log buffer into video memory
>
> This patch adds new kernel parameter printk_address=
> that will allow it to store the printk buffer in arbitary
> (I/O) memory address.
>
> If you own a system that has discrete video ram, and it
> isn't cleared automatically by BIOS on reboot, you
> can use this as a black box recorder of crashes.
>
> If debugfs is enabled, log of last boot is copied into
> system ram, and can be accessed via debugfs, for example
> cat /sys/kernel/debug/printk/crash_dmesg
>
> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
> ---
> kernel/printk.c | 102 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> lib/Kconfig.debug | 31 ++++++++++++++++
> 2 files changed, 133 insertions(+), 0 deletions(-)
kernel/printk.c does not seem to be the right place to do that
but rather in a specific console driver.
I would rather see it as an early console (for early printk), beside ttyS,
vga and usb debug ports.
Also, instead of creating another debugfs entry, you could just
trigger the trace to the ftrace ring buffer, using trace_printk()
for example.
Hm?
I personally would like to see such feature as I have no serial line
in my laptop, although I'm not sure my graphical card would be happy
with that...
Thanks.
next prev parent reply other threads:[~2009-11-22 2:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-22 2:05 RFC: Put printk buffer in video ram Maxim Levitsky
2009-11-22 2:32 ` Frederic Weisbecker [this message]
2009-11-22 8:25 ` Ingo Molnar
2009-11-22 12:15 ` Maxim Levitsky
2009-11-23 1:01 ` Maxim Levitsky
2009-11-23 18:32 ` Ingo Molnar
2009-11-23 18:55 ` Chris Friesen
2009-11-23 19:03 ` Arnd Bergmann
2009-11-23 19:03 ` Arnd Bergmann
2009-11-22 12:07 ` Maxim Levitsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091122023237.GA6572@nowhere \
--to=fweisbec@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maximlevitsky@gmail.com \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.