Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: jpt@uf.msc.umn.edu (Joseph Thomas)
Newsgroups: comp.sys.sun
Subject: Re: Sun 3 console question
Keywords: SunOS
Message-ID: <8902231905.AA12114@uf.msc.umn.edu>
Date: 5 Mar 89 23:11:24 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 35
Approved: Sun-Spots@rice.edu
Original-Date: Thu, 23 Feb 89 13:05:22 CST
X-Sun-Spots-Digest: Volume 7, Issue 182, message 3 of 17

Hey, this sounds like one we just fixed !! This had been driving us crazy
for sometime. Even renaming/removing /dev/fb et. al. didn't seem to help.
We could usually get the console back by killing the associated
shell/getty for the tty port. The cincher was when one of our users
reported getting the sysop's prompt on his tty. 

The culprit ( for us anyways ) was having a process steal the console via
a TIOCCONS ioctl control. Seems lots of window systems like doing this (
for valid reasons ) and several X-terms we'd be testing. You can verify
this next time it happens by adb'ing the kernel and looking at the value
of 'consdev'

[
	$ adb /vmunix /dev/kmem
	consdev/x
	$q
]

Valid values for using /dev/ttya or /dev/ttyb are 'c00' or 'c01'. These
are the major/minor device numbers of the current 'console'. [ On a system
with a frame buffer, this would be '0' with out a window system running,
and the device number of some pty with windows ( such as '1400' for
/dev/ttyp0 ) ] If it's not the real tty device, you should be able to
track down the owner of the pty and find out what he/she's running.

Using source, we added a check in sys/tty_pty.c to make sure that the
current console device is 0 ( the frame buffer ) before allowing the ioctl
to complete. If it's not, someone else has the console, or it shouldn't be
allowd to change. This seems to work with all our testing, we have yet to
put it into production during the next coule of weeks.

Joseph Thomas
Minnesota Supercomputer Center
jpt@msc.umn.edu
612/626-1888