All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Fabio M. Di Nitto" <fdinitto@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Fabio M. Di Nitto" <fabbione@fabbione.net>,
	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>
Subject: Re: [PATCH] console: allow to retain boot console via boot option keep_bootcon
Date: Thu, 27 Jan 2011 15:35:19 +0100	[thread overview]
Message-ID: <4D4182A7.5050503@redhat.com> (raw)
In-Reply-To: <4D37D18D.9060402@redhat.com>

Hi all,

On 1/20/2011 7:09 AM, Fabio M. Di Nitto wrote:
> On 01/20/2011 01:19 AM, Andrew Morton wrote:
>> 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.
> 
> 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.

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

Fabio

  reply	other threads:[~2011-01-27 14:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-12  8:40 [PATCH] console: allow to retain boot console via boot option keep_bootcon Fabio M. Di Nitto
2011-01-20  0:19 ` Andrew Morton
2011-01-20  6:09   ` Fabio M. Di Nitto
2011-01-27 14:35     ` Fabio M. Di Nitto [this message]
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=4D4182A7.5050503@redhat.com \
    --to=fdinitto@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=fabbione@fabbione.net \
    --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 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.