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 <[email protected]>
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 <[email protected]>
---
kernel/printk.c | 102 +++++++++++++++++++++++++++++++++++++++++++++++++++++
lib/Kconfig.debug | 31 ++++++++++++++++
2 files changed, 133 insertions(+), 0 deletions(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index f38b07f..c6a6f6a 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -33,6 +33,7 @@
#include <linux/bootmem.h>
#include <linux/syscalls.h>
#include <linux/kexec.h>
+#include <linux/debugfs.h>
#include <asm/uaccess.h>
@@ -143,6 +144,7 @@ static char __log_buf[__LOG_BUF_LEN];
static char *log_buf = __log_buf;
static int log_buf_len = __LOG_BUF_LEN;
static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
+static unsigned int printk_address;
#ifdef CONFIG_KEXEC
/*
@@ -167,6 +169,9 @@ static int __init log_buf_len_setup(char *str)
unsigned size = memparse(str, &str);
unsigned long flags;
+ if (printk_address)
+ return 1;
+
if (size)
size = roundup_pow_of_two(size);
if (size > log_buf_len) {
@@ -203,6 +208,103 @@ out:
__setup("log_buf_len=", log_buf_len_setup);
+
+#ifdef CONFIG_HWMEM_PRINTK
+
+#define EARLY_LOG_PAGES (8 * PAGE_SIZE)
+char *old_log_buf;
+struct debugfs_blob_wrapper crash_dmesg_wrapper;
+
+static int __init printk_address_setup(char *str)
+{
+ unsigned long flags;
+ void *mem_address;
+
+ get_option(&str, &printk_address);
+ if (!printk_address)
+ return 0;
+
+ /* temporarly map first few pages of log memory */
+ mem_address = early_ioremap(printk_address, EARLY_LOG_PAGES);
+ if (!mem_address)
+ return 0;
+
+ printk(KERN_INFO "Logging kernel messages into HW memory at %08x\n",
+ printk_address);
+ /* allocate saved log buffer, and save the log memory that we
+ will otherwise overwrite */
+ old_log_buf = alloc_bootmem(__LOG_BUF_LEN);
+ if (old_log_buf)
+ memcpy(old_log_buf, mem_address, EARLY_LOG_PAGES);
+
+ /* clear log memory now */
+ memset(mem_address, 0, EARLY_LOG_PAGES);
+
+ /* copy current printk buffer to log memory, and switch to new buffer */
+ spin_lock_irqsave(&logbuf_lock, flags);
+ memcpy(mem_address, log_buf, EARLY_LOG_PAGES);
+ log_buf = mem_address;
+ log_buf_len = EARLY_LOG_PAGES;
+ spin_unlock_irqrestore(&logbuf_lock, flags);
+
+ return 1;
+}
+__setup("printk_address=", printk_address_setup);
+
+static int printk_address_late(void)
+{
+
+ char *mem_address, *early_mem_address;
+ unsigned long flags;
+ struct dentry *dbgfs_dir;
+
+ if (!printk_address)
+ return 0;
+
+ /* now do late initialization */
+ mem_address = ioremap(printk_address, __LOG_BUF_LEN);
+
+ if (!mem_address) {
+ printk(KERN_ALERT "Can't fully map hardware kernel log memory."
+ " Log buffer limited to %lu KB\n", EARLY_LOG_PAGES);
+ return 0;
+ }
+
+ /* save the rest of log memory, and publish it */
+ if (old_log_buf) {
+ memcpy(old_log_buf + EARLY_LOG_PAGES,
+ mem_address + EARLY_LOG_PAGES,
+ __LOG_BUF_LEN - EARLY_LOG_PAGES);
+
+ crash_dmesg_wrapper.data = old_log_buf;
+ crash_dmesg_wrapper.size = __LOG_BUF_LEN;
+
+ dbgfs_dir = debugfs_create_dir("printk", NULL);
+
+ if (dbgfs_dir > 0)
+ debugfs_create_blob("crash_dmesg", S_IRUSR, dbgfs_dir,
+ &crash_dmesg_wrapper);
+ }
+
+ /* clear rest of the log memory now */
+ memset(mem_address + EARLY_LOG_PAGES , 0,
+ __LOG_BUF_LEN - EARLY_LOG_PAGES);
+
+
+ /* switch to the full log memory now */
+ spin_lock_irqsave(&logbuf_lock, flags);
+ early_mem_address = log_buf;
+ log_buf = mem_address;
+ log_buf_len = __LOG_BUF_LEN;
+ spin_unlock_irqrestore(&logbuf_lock, flags);
+
+ /* free temp mapping of the log memory */
+ early_iounmap(early_mem_address, EARLY_LOG_PAGES);
+ return 1;
+}
+postcore_initcall(printk_address_late);
+#endif
+
#ifdef CONFIG_BOOT_PRINTK_DELAY
static unsigned int boot_delay; /* msecs delay after each printk during bootup */
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 234ceb1..e5788b1 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -716,6 +716,37 @@ config BOOT_PRINTK_DELAY
BOOT_PRINTK_DELAY also may cause DETECT_SOFTLOCKUP to detect
what it believes to be lockup conditions.
+config HWMEM_PRINTK
+ bool "Log printk message buffer into video ram (DANGEROUS)"
+ depends on DEBUG_KERNEL && PRINTK
+ help
+ This option allows to place kernel log buffer into pre-defined
+ area, somewhere in memory space.
+ It is intended to place this buffer into video ram assuming it
+ isn't cleared on reboot.
+ This creates some sort of black box recorder and can be very useful
+ to debug several problems, especially 'panics' that happen while you
+ use the X window system.
+
+ To use, first ensure that you aren't using X, or that you tell video
+ driver not to use all the video ram
+ (easy way is to use the 'vesa' X driver)
+
+ Then, pick an address within the video memory,
+ (best somewhere in middle), and boot kernel with
+ printk_address=$ADDRESS
+
+ If you also select debugfs support, you can easily look at
+ kernel log of failed boot at:
+ /sys/kernel/debug/printk/crash_dmesg
+
+ (Assuming you mounted debugfs on /sys/kernel/debug)
+
+ Misuse of this option can be DANGEROUS, as it makes kernel write at
+ arbitrary (selected by you) hardware memory range.
+
+ It is only intended for debugging, so say 'no' if not sure
+
config RCU_TORTURE_TEST
tristate "torture tests for RCU"
depends on DEBUG_KERNEL
--
1.6.3.3
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 <[email protected]>
> 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 <[email protected]>
> ---
> 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.
* Frederic Weisbecker <[email protected]> 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.
The idea is very, very nice!
If implemented cleanly and with a few more usability fixes this could be
a killer feature for laptop debugging. Persistent storage across reboots
- that's really nice.
( It wont help us debug crashes that require a power cycle - so it
probably will not help with s2ram failure debugging - but still it
widens the scope of printk based logging to critical crash scenarios:
early bootup crashes can be debugged via it and panics can be debugged
via it as well - as long as panic_timeout still works. )
> > Best regards,
> > Maxim Levitsky
> >
> > ---
> >
> > >From 77e0f4ffc531417d54ce928ade8481d82192b012 Mon Sep 17 00:00:00 2001
> > From: Maxim Levitsky <[email protected]>
> > 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 <[email protected]>
> > ---
> > 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...
I'd like to make it easy for distros to pipe regular printk's into this
buffer as well - and not tie it to some hassle-to-set-up early printk
mechanism. (early printk should tie into it too, to make it easier to
debug early crashes. User first boots into a kernel that crashes - then
can 'recover' the crashlog on a known-good kernel.)
But i agree with your observation that the hw dependent bits should not
go into kernel/printk.c - but this could be done cleanly at the console
driver level and be added to the VGA driver.
It should probably also tie into KMS/GEM to make sure it does not stomp
over video RAM that the GX driver might be using.
Furthermore, the printk_address=xyz boot parameter is way too difficult
for users to get right. This should be done as automatically as possible
- and the 'previous' printk buffer should be dumped into the 'next'
printk buffer during bootup. (preserving it for the regular syslog in a
compatible way and for kerneloops, etc.)
Creating a new /sys output channel just delays the adoption of such a
feature forever. It should be part of the printk infrastructure,
enable-able via a .config option but automatic otherwise.
Ingo
On Sun, 2009-11-22 at 03:32 +0100, Frederic Weisbecker 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.
> >
> >
> > Best regards,
> > Maxim Levitsky
> >
> > ---
> >
> > >From 77e0f4ffc531417d54ce928ade8481d82192b012 Mon Sep 17 00:00:00 2001
> > From: Maxim Levitsky <[email protected]>
> > 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 <[email protected]>
> > ---
> > 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 more or less agree that printk.c isn't right place for that, but
the way I did it ensures that as soon as messages are printed, they are
in the log buffer. Doing that using early console driver might not
capture all messages. For example, for suspend/resume cycle unless
no_console_suspend is passed, it would block output to all consoles.
Also, isn't early console only enabled before regular console kicks in?
I think there is a kconfig option to keep it, but I would like to make
this feature permanent independently.
> 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.
It isn't a bad idea, but this adds yet another requirement, this is user
will need to enable the ftrace, and know how to read this log buffer.
simple 'cat' is easier, but I am not against implementing both.
>
> 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...
You can always use 'vesa' Xorg driver. It will only access the
framebuffer. anything beyond that is very likely to be available.
I own an nvidia device, and I patched the 'nv' driver for fixed amount
of memory.
>
> Thanks.
>
Best regards,
Maxim Levitsky
On Sun, 2009-11-22 at 09:25 +0100, Ingo Molnar wrote:
> * Frederic Weisbecker <[email protected]> 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.
>
> The idea is very, very nice!
>
> If implemented cleanly and with a few more usability fixes this could be
> a killer feature for laptop debugging. Persistent storage across reboots
> - that's really nice.
>
> ( It wont help us debug crashes that require a power cycle - so it
> probably will not help with s2ram failure debugging - but still it
> widens the scope of printk based logging to critical crash scenarios:
> early bootup crashes can be debugged via it and panics can be debugged
> via it as well - as long as panic_timeout still works. )
>
> > > Best regards,
> > > Maxim Levitsky
> > >
> > > ---
> > >
> > > >From 77e0f4ffc531417d54ce928ade8481d82192b012 Mon Sep 17 00:00:00 2001
> > > From: Maxim Levitsky <[email protected]>
> > > 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 <[email protected]>
> > > ---
> > > 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...
>
> I'd like to make it easy for distros to pipe regular printk's into this
> buffer as well - and not tie it to some hassle-to-set-up early printk
> mechanism. (early printk should tie into it too, to make it easier to
> debug early crashes. User first boots into a kernel that crashes - then
> can 'recover' the crashlog on a known-good kernel.)
>
> But i agree with your observation that the hw dependent bits should not
> go into kernel/printk.c - but this could be done cleanly at the console
> driver level and be added to the VGA driver.
Same question, will this always work?
I would like the kernel buffer always to go into the video ram, but
there is a chance that console driver won't be called (during
suspend/resume for example)
How to do that?
>
> It should probably also tie into KMS/GEM to make sure it does not stomp
> over video RAM that the GX driver might be using.
I have here an nvidia card.
Hooking this feature into kms would be really nice, but currently is
only useful for AMD users. I haven't yet tried nouveau driver, but I
think it isn't yet stable enough to be used.
>
> Furthermore, the printk_address=xyz boot parameter is way too difficult
> for users to get right. This should be done as automatically as possible
> - and the 'previous' printk buffer should be dumped into the 'next'
> printk buffer during bootup. (preserving it for the regular syslog in a
> compatible way and for kerneloops, etc.)
This isn't a bad idea at all, I add that feature.
>
> Creating a new /sys output channel just delays the adoption of such a
> feature forever. It should be part of the printk infrastructure,
> enable-able via a .config option but automatic otherwise.
Agree.
Best regards,
Maxim Levitsky
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 <[email protected]> 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
* Maxim Levitsky <[email protected]> wrote:
> 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 <[email protected]> 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.
Adding an early console driver would solve this, right?
There's an earlyprintk=..,keep option that also allows such a console
driver to be active during normal system operation - that way you could
get this feature with a single console driver.
> 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.
The way to early-reserve memory on x86 is to use find_e820_area() +
reserve_early().
Ingo
On 11/23/2009 12:32 PM, Ingo Molnar wrote:
>
> * Maxim Levitsky <[email protected]> wrote:
>
>> 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 <[email protected]> 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.
>
> Adding an early console driver would solve this, right?
We've had a mechanism sort of like this for quite a while. Hasn't been
pushed to mainline because it used board-specific hardware and we're
usually multiple kernel versions behind mainline.
Anyways, a couple things that we've found to be useful are:
1) The ability to allocate a chunk of this persistent memory area for a
special purpose. This allows things like memory-mapped circular buffers
for per-cpu binary data.
2) An API to log just to this persistent area and bypass the normal
console completely. This can be useful when debugging issues where the
normal logging paths result in a hang.
Chris
On Monday 23 November 2009, Chris Friesen wrote:
> We've had a mechanism sort of like this for quite a while. Hasn't been
> pushed to mainline because it used board-specific hardware and we're
> usually multiple kernel versions behind mainline.
>
> Anyways, a couple things that we've found to be useful are:
> 1) The ability to allocate a chunk of this persistent memory area for a
> special purpose. This allows things like memory-mapped circular buffers
> for per-cpu binary data.
> 2) An API to log just to this persistent area and bypass the normal
> console completely. This can be useful when debugging issues where the
> normal logging paths result in a hang.
Some powerpc machines have a memory-mapped nvram, in which the kernel
can install persistant 'partitions'. Not all of them are memory mapped,
but for those that are (e.g. IBM QS22), your approach sounds perfect.
Arnd <><