strange behaviour with /sbin/init and serial console
koitsu at FreeBSD.org
Fri Oct 31 14:09:07 PDT 2008
On Fri, Oct 31, 2008 at 01:28:02PM -0600, Scott Long wrote:
> Ed Schouten wrote:
>> Hello Theirry,
>> * Thierry Herbelot <thierry.herbelot at free.fr> wrote:
>>> with the following patch on /sbin/init, I have two different
>>> behaviours depending on the console type (on a i386/32 PC) :
>>> - on a video console, I see the expected two messages,
>>> - on a serial console, the messages are not displayed (init silently
>>> finishes its job and gets to start /etc/rc and everything)
>>> I assume that the writev system call is implemented in
>>> src/sys/kern/tty_cons.c::cnwrite(), but I could not parse the code to
>>> find an explanation.
>>> any taker ?
>>> PS : this is initially for a RELENG_6 machine, but the code is quite
>>> similar under RELENG_7 or Current
>> Any data written to /dev/console is not multiplexed to all console
>> devices, but only the first active device in the list. The reason behind
>> this, is because it adds a real lot of complexity to the console code,
>> especially related to polling and reading on /dev/console.
>> This weekend I'm going to commit a replacement implementation of
>> /dev/console, which also has this restriction.
> The multiplexed console feature is one thing that linux got right. In a
> corporate setting, you really need both a serial console and a video
> console in order to effectively manage the machines, as you want to be
> able to access them both remotely and locally.
I know this comment isn't much help, but, I am in full agreement with
Scott. FreeBSD's lack of *true* multi (or even dual) console during all
stages is a big disappointment to server administrators. The common
reaction is: "What do you mean I can only get some messages on serial or
some messages on VGA?! That's retarded!"
I believe DragonFly has addressed this (offering a true dual console
mechanism), and if I remember correctly, Matt Dillon discussed the code
changes in great detail, citing a large amount of re-engineering
required to accomplish it.
> While it might be hard to build multiplexing into the console driver,
> do you think it would be possible to layer a multiplexer on top of it,
> similar to how the kbdmux driver works?
Let's make sure that we don't implement it identically though, as there
are many of us who have major problems with kbdmux (reports of LORs, and
even more reports of incredibly slow keyboard input when a USB keyboard
is used; workarounds are either disabling atkbd/atkbdc entirely, or
disabling kbdmux entirely. In my case, I found the latter to be
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
More information about the freebsd-hackers