From owner-freebsd-current Mon Oct 23 08:56:51 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA11577 for current-outgoing; Mon, 23 Oct 1995 08:56:51 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA11572 for ; Mon, 23 Oct 1995 08:56:45 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA07962; Tue, 24 Oct 1995 01:56:18 +1000 Date: Tue, 24 Oct 1995 01:56:18 +1000 From: Bruce Evans Message-Id: <199510231556.BAA07962@godzilla.zeta.org.au> To: bde@zeta.org.au, fredriks@mcs.com Subject: Re: ordering of isa_devtab_tty important? Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk >> The support for syscons and pcvt in the same kernel broke it :(. >> find_display() in isa.c requires display devices to be before serial >> devices, not to mention before devices in isa_devtab_tty that aren't >> really ttys. It could abuse the `sensitive_hw' flag to select the >> display devices. Display devices aren't sensitive, but the sensitive_hw >> flag is set for them so that they get probed early so that they don't >> appear to be used before they are detected. >So we need to fix config so that we can tell it what devices are able >to serve as a console, and to make it put the real console devices in front >of the serial ports in the table, and the other, non colsole able, at the end >of the table.. I think we might be asking for trouble having config put >together the list based upon the order it occurs in the file. I committed a quick fix yesterday (only sensitive devices are considered as displays). Config probably shouldn't know anything about what devices can be consoles, but the perhaps the console priority should be configurable. There is an unused `priority' keyword. The file order is usually good enough. >> This happens because sio0 becomes the console. You should get a login >> prompt if the boot succeeds and you wait a little longer. >Hm, even if the second device in the table is sc0? I guess I would expect the >code just to walk down the table until it finds a console it can talk to rather >than using sio0 if the first one failed(this does make it more predictable >though :-)). sc0 thinks vt0 is going to become the console, and vt0 thinks sc0 is going to become the console, so neither becomes the console and the console becomes sio0 by default. sio0 should sometimes think another tty driver will claim the console but that isn't implemented yet :-). Bruce