[PATCH] console: allow to retain boot console via boot option keep_bootcon
Fabio M. Di Nitto
On some architectures, the boot process involves de-registering the boot
console (early boot), initialize drivers and then re-register the console.
This mechanism introduces a window in which no printk can happen on the console
and messages are buffered and then printed once the new console is available.
If a kernel crashes during this window, all it's left on the boot console
is "console [foo] enabled, bootconsole disabled" making debug of the crash
rather 'interesting'.
By adding "keep_bootcon" option, do not unregister the boot console, that
will allow to printk everything that is happening up to the crash.
The option is clearly meant only for debugging purposes as it introduces lots
of duplicated info printed on console, but will make bug report from users
easier as it doesn't require a kernel build just to figure out where we crash.
Signed-off-by: Fabio M. Di Nitto <fabb...@fabbione.net>
Acked-by: David S. Miller <da...@davemloft.net>
---
Documentation/kernel-parameters.txt | 6 ++++++
kernel/printk.c | 16 +++++++++++++++-
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index ed3708f..824642c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -869,6 +869,12 @@ and is between 256 and 4096 characters. It is defined in the file
If specified, z/VM IUCV HVC accepts connections
from listed z/VM user IDs only.
+ keep_bootcon [KNL]
+ Do not unregister boot console at start. This is only
+ useful for debugging when something happens in the window
+ between unregistering the boot console and initializing
+ the real console.
+
i2c_bus= [HW] Override the default board specific I2C bus speed
or register an additional I2C bus that is not
registered from board initialization code.
diff --git a/kernel/printk.c b/kernel/printk.c
index f64b899..c952eb2 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -1221,6 +1221,18 @@ void console_start(struct console *console)
}
EXPORT_SYMBOL(console_start);
+static int __read_mostly keep_bootcon;
+
+static int __init keep_bootcon_setup(char *str)
+{
+ keep_bootcon = 1;
+ printk(KERN_INFO "debug: skip boot console de-registration.\n");
+
+ return 0;
+}
+
+early_param("keep_bootcon", keep_bootcon_setup);
+
/*
* The console driver calls this routine during kernel initialization
* to register the console printing procedure with printk() and to
@@ -1368,7 +1380,9 @@ void register_console(struct console *newcon)
* users know there might be something in the kernel's log buffer that
* went to the bootconsole (that they do not see on the real console)
*/
- if (bcon && ((newcon->flags & (CON_CONSDEV | CON_BOOT)) == CON_CONSDEV)) {
+ if (bcon &&
+ ((newcon->flags & (CON_CONSDEV | CON_BOOT)) == CON_CONSDEV) &&
+ !keep_bootcon) {
/* we need to iterate through twice, to make sure we print
* everything out, before we unregister the console(s)
*/
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
"Fabio M. Di Nitto" <fabb...@fabbione.net> wrote:
> From: Fabio M. Di Nitto <fdin...@redhat.com>
>
> On some architectures, the boot process involves de-registering the boot
> console (early boot), initialize drivers and then re-register the console.
>
> This mechanism introduces a window in which no printk can happen on the console
> and messages are buffered and then printed once the new console is available.
>
> If a kernel crashes during this window, all it's left on the boot console
> is "console [foo] enabled, bootconsole disabled" making debug of the crash
> rather 'interesting'.
>
> By adding "keep_bootcon" option, do not unregister the boot console, that
> will allow to printk everything that is happening up to the crash.
>
> The option is clearly meant only for debugging purposes as it introduces lots
> of duplicated info printed on console, but will make bug report from users
> easier as it doesn't require a kernel build just to figure out where we crash.
>
I don't get it, as usual.
The architecture does
a) deregister boot console
b) initialize drivers
c) register console
and the patch basically disables step a).
But if we can do that without screwing things up, why not simply change
the architecture to not deregister the boot console until after
initializing the drivers?
Fabio M. Di Nitto
> On Wed, 12 Jan 2011 09:40:24 +0100
> "Fabio M. Di Nitto" <fabb...@fabbione.net> wrote:
>
>> From: Fabio M. Di Nitto <fdin...@redhat.com>
>>
>> On some architectures, the boot process involves de-registering the boot
>> console (early boot), initialize drivers and then re-register the console.
>>
>> This mechanism introduces a window in which no printk can happen on the console
>> and messages are buffered and then printed once the new console is available.
>>
>> If a kernel crashes during this window, all it's left on the boot console
>> is "console [foo] enabled, bootconsole disabled" making debug of the crash
>> rather 'interesting'.
>>
>> By adding "keep_bootcon" option, do not unregister the boot console, that
>> will allow to printk everything that is happening up to the crash.
>>
>> The option is clearly meant only for debugging purposes as it introduces lots
>> of duplicated info printed on console, but will make bug report from users
>> easier as it doesn't require a kernel build just to figure out where we crash.
>>
>
> I don't get it, as usual.
It might just be my itaglish explanation :)
>
> The architecture does
>
> a) deregister boot console
> b) initialize drivers
> c) register console
>
> and the patch basically disables step a).
Yes that is correct.
>
> But if we can do that without screwing things up, why not simply change
> the architecture to not deregister the boot console until after
> initializing the drivers?
I am not entirely sure if this is possible (or even worth it since this
is a pure debugging option) and what kind of effects it might have on
the boot output (in terms of duplicated entries on the output that might
or might not make it more difficult to read). I am happy to investigate
that and come back to you soon.
Thanks for taking your time to review this patch.
Fabio
Fabio M. Di Nitto
I have been looking into your suggestion and I think this is what
already happens.
According to kernel/print.k:
> /*
> * By unregistering the bootconsoles after we enable the real console
> * we get the "console xxx enabled" message on all the consoles -
> * boot consoles, real consoles, etc - this is to ensure that end
> * users know there might be something in the kernel's log buffer that
> * went to the bootconsole (that they do not see on the real console)
> */
but my understanding, and please correct if I am wrong, is that when we
load or initialize modules such as fbcon (I made this patch debugging a
crash in atyfb), a console is indeed registered and bootconsole disable,
while in reality the real console is not there yet (in my case fbcon was
loaded but not atyfb yet).
At a later stage, once atyfb is loaded, it registers with fbcon and then
the console output starts again.
Thanks again for your time
David Miller
> According to kernel/print.k:
>
>> /*
>> * By unregistering the bootconsoles after we enable the real console
>> * we get the "console xxx enabled" message on all the consoles -
>> * boot consoles, real consoles, etc - this is to ensure that end
>> * users know there might be something in the kernel's log buffer that
>> * went to the bootconsole (that they do not see on the real console)
>> */
>
> but my understanding, and please correct if I am wrong, is that when we
> load or initialize modules such as fbcon (I made this patch debugging a
> crash in atyfb), a console is indeed registered and bootconsole disable,
> while in reality the real console is not there yet (in my case fbcon was
> loaded but not atyfb yet).
> At a later stage, once atyfb is loaded, it registers with fbcon and then
> the console output starts again.
It's not exactly "fbcon", it's the "VT" driver.
That loads, and nothing has attached to VT yet to provide the actual
console hookup.
"fbcon" waits until a usable driver registers before it hooks itself
into the "VT" layer.
So this is why we have this large gap of time with no console output.
It's because VT registers before it actually is able to provide
console output services, and frankly that's a bug. :-)
Fabio M. Di NItto
> From: "Fabio M. Di Nitto" <fdin...@redhat.com>
> Date: Thu, 27 Jan 2011 15:35:19 +0100
>
>> According to kernel/print.k:
>>
>>> /*
>>> * By unregistering the bootconsoles after we enable the real console
>>> * we get the "console xxx enabled" message on all the consoles -
>>> * boot consoles, real consoles, etc - this is to ensure that end
>>> * users know there might be something in the kernel's log buffer that
>>> * went to the bootconsole (that they do not see on the real console)
>>> */
>>
>> but my understanding, and please correct if I am wrong, is that when we
>> load or initialize modules such as fbcon (I made this patch debugging a
>> crash in atyfb), a console is indeed registered and bootconsole disable,
>> while in reality the real console is not there yet (in my case fbcon was
>> loaded but not atyfb yet).
>> At a later stage, once atyfb is loaded, it registers with fbcon and then
>> the console output starts again.
>
> It's not exactly "fbcon", it's the "VT" driver.
Thanks for the clarification. I spotted both VT and fbcon (as they are
the only two that register as console driver effectively) and of course
picked the wrong one ;)
> That loads, and nothing has attached to VT yet to provide the actual
> console hookup.
at least I got this part right...
>
> "fbcon" waits until a usable driver registers before it hooks itself
> into the "VT" layer.
>
> So this is why we have this large gap of time with no console output.
> It's because VT registers before it actually is able to provide
> console output services, and frankly that's a bug. :-)
Ok, I have no idea how complex and delicate that code is, but I'll try
to see if we can actually fix VT to behave as fbcon rather than adding
this patch as workaround.
Thanks
Fabio