From: Ralf Baechle <ralf@oss.sgi.com>
To: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
Cc: "Kevin D. Kissell" <kevink@mips.com>,
linux-mips@oss.sgi.com, Klaus Naumann <spock@mgnet.de>,
Jesse Dyson <jesse@winston-salem.com>
Subject: Re: Indigo2 Kernel Boots!!!
Date: Fri, 1 Dec 2000 18:53:21 +0100 [thread overview]
Message-ID: <20001201185321.A3211@bacchus.dhis.org> (raw)
In-Reply-To: <XFMail.001201163348.Harald.Koerfgen@home.ivm.de>; from Harald.Koerfgen@home.ivm.de on Fri, Dec 01, 2000 at 04:33:48PM +0100
On Fri, Dec 01, 2000 at 04:33:48PM +0100, Harald Koerfgen wrote:
> > Having been through the exercise a dozen or more times with
> > the SGI 2.2 kernel distributions for the Indy, I would be fascinated
> > to know what bug I was painting over, and where the correct
> > procedure was documented.
>
> linux/Documentation/serial-console.txt
In addition let me add some word about what the term console actually is,
this commonly seems to cause confusition because the word is used with two
different meanings:
1) The device on which you login in single user mode, that's usually some
kind of serial device at ttyS0 or a virtual console, that is with keyboard
and some kind of text terminal.
2) The second is the device which the kernel prints all the printk messages
and data sent to /dev/console to. The two often often but not always
refer to the same actual device.
/dev/console (as chardev 5/1) differs from another device in some important
ways:
- When opened by a process without controlling tty it will not become a
CTTY even if the NOCTTY flag is not set.
- It will never block but rather loose data. This may sound like a
disadvantage but it's actually very important for proper operation. For
example, if /dev/console'd block due to a serial console with hardware
handshaking enabled (DON'T) syslogd writing to it may also block for an
unbounded time and thus as soon as /dev/log is full all services trying to
log via syslog(3) will also freeze.
Syslogd actually tries to be clever about avoiding this from happening
but fails to handle one case correctly, so this is a real world scenario.
- It uses different routines to access the console device than normal
write access to i.e. ttyS0.
The most common problem is that CONFIG_SERIAL_CONSOLE wasn't configured;
some drivers are simply buggy and don't properly register the console
on startup. Dunno what the problem was in your case, Kevin.
Ralf
next prev parent reply other threads:[~2000-12-01 17:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-30 6:48 Indigo2 Kernel Boots!!! Jesse Dyson
2000-11-30 7:53 ` Klaus Naumann
2000-11-30 14:41 ` Jesse Dyson
2000-11-30 15:56 ` Keith M Wesolowski
2000-11-30 16:10 ` Kevin D. Kissell
2000-11-30 16:10 ` Kevin D. Kissell
2000-11-30 23:59 ` Ralf Baechle
2000-12-01 7:22 ` Kevin D. Kissell
2000-12-01 7:22 ` Kevin D. Kissell
2000-12-01 15:33 ` Harald Koerfgen
2000-12-01 17:53 ` Ralf Baechle [this message]
2000-12-01 18:15 ` console knowledge Gordon McNutt
2000-12-02 1:53 ` Ralf Baechle
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=20001201185321.A3211@bacchus.dhis.org \
--to=ralf@oss.sgi.com \
--cc=Harald.Koerfgen@home.ivm.de \
--cc=jesse@winston-salem.com \
--cc=kevink@mips.com \
--cc=linux-mips@oss.sgi.com \
--cc=spock@mgnet.de \
/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