From: Andrew Morton <akpm@linux-foundation.org>
To: "Fabio M. Di Nitto" <fabbione@fabbione.net>
Cc: Randy Dunlap <rdunlap@xenotime.net>,
James Morris <jmorris@namei.org>,
Kees Cook <kees.cook@canonical.com>, Ingo Molnar <mingo@elte.hu>,
Namhyung Kim <namhyung@gmail.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Daid Miller <davem@davemloft.net>,
"Fabio M. Di Nitto" <fdinitto@redhat.com>
Subject: Re: [PATCH] console: allow to retain boot console via boot option keep_bootcon
Date: Wed, 19 Jan 2011 16:19:18 -0800 [thread overview]
Message-ID: <20110119161918.1f827080.akpm@linux-foundation.org> (raw)
In-Reply-To: <1294821624-24544-1-git-send-email-fabbione@fabbione.net>
On Wed, 12 Jan 2011 09:40:24 +0100
"Fabio M. Di Nitto" <fabbione@fabbione.net> wrote:
> From: Fabio M. Di Nitto <fdinitto@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?
next prev parent reply other threads:[~2011-01-20 0:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-12 8:40 Fabio M. Di Nitto
2011-01-20 0:19 ` Andrew Morton [this message]
2011-01-20 6:09 ` Fabio M. Di Nitto
2011-01-27 14:35 ` Fabio M. Di Nitto
2011-01-27 20:47 ` David Miller
2011-01-27 20:52 ` Fabio M. Di NItto
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=20110119161918.1f827080.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=fabbione@fabbione.net \
--cc=fdinitto@redhat.com \
--cc=jmorris@namei.org \
--cc=kees.cook@canonical.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=namhyung@gmail.com \
--cc=rdunlap@xenotime.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome