From: Andrew Morton <akpm@osdl.org>
To: Greg Edwards <edwardsg@sgi.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] CON_CONSDEV bit not set correctly on last console
Date: Wed, 6 Apr 2005 15:53:17 -0700 [thread overview]
Message-ID: <20050406155317.54792458.akpm@osdl.org> (raw)
In-Reply-To: <20050405191003.GO21725@sgi.com>
Greg Edwards <edwardsg@sgi.com> wrote:
>
> According to include/linux/console.h, CON_CONSDEV flag should be set on
> the last console specified on the boot command line:
>
> 86 #define CON_PRINTBUFFER (1)
> 87 #define CON_CONSDEV (2) /* Last on the command line */
> 88 #define CON_ENABLED (4)
> 89 #define CON_BOOT (8)
>
> This does not currently happen if there is more than one console specified
> on the boot commandline. Instead, it gets set on the first console on the
> command line. This can cause problems for things like kdb that look for
> the CON_CONSDEV flag to see if the console is valid.
>
> Additionaly, it doesn't look like CON_CONSDEV is reassigned to the next
> preferred console at unregister time if the console being unregistered
> currently has that bit set.
>
> Example (from sn2 ia64):
>
> elilo vmlinuz root=<dev> console=ttyS0 console=ttySG0
>
> in this case, the flags on ttySG console struct will be 0x4 (should be
> 0x6).
>
> Attached patch against bk fixes both issues for the cases I looked at. It
> uses selected_console (which gets incremented for each console specified
> on the command line) as the indicator of which console to set CON_CONSDEV
> on. When adding the console to the list, if the previous one had
> CON_CONSDEV set, it masks it out. Tested on ia64 and x86.
The `console=a console=b' behaviour seem basically random to me :(. And it
gets re-randomised on a regular basis.
I wonder if we should leave the existing behaviour alone (continue to set
CON_CONSDEV on the first console) and just change the documentation?
That'll minimise the disruption which we cause.
next prev parent reply other threads:[~2005-04-06 22:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-05 19:10 Greg Edwards
2005-04-06 22:53 ` Andrew Morton [this message]
2005-04-06 23:48 ` Miquel van Smoorenburg
2005-04-07 2:11 ` Greg Edwards
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=20050406155317.54792458.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=edwardsg@sgi.com \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®