erickson@frith.egr.msu.edu (Carl B. Erickson) (01/31/89)
Can someone point me to the fix that has been discussed for using a terminal as the console on a Sun 3? I believe this involved a small circuit of some sort. Carl Erickson erickson@frith.egr.msu.edu uunet!frith!erickson
casey@lll-crg.llnl.gov (Casey Leedom) (02/22/89)
erickson@frith.egr.msu.edu (Carl B. Erickson): > Can someone point me to the fix that has been discussed for using a > terminal as the console on a Sun 3? I believe this involved a small > circuit of some sort. This brings a question up to the top of my queue that I've been meaning to ask for months. Nearly two years now in fact: We use standard ascii terminals as the consoles of all our file servers. After the systems have been up for a while, the terminals lock up and we haven't figured out how to break them out of that mode. This happens reliably on two 3/180s and a 3/280 running SUN OS 3.4, and two 3/280s running SUN OS 3.5 on a whole variety of terminals. The file servers are still running and we can log into them across the net without any problems. But if we want to use the console, the only way we've been able to come up with is to reboot the servers. Whenever I mention this problem to a Sun person they just look blankly at me. I can't believe it's unique to us. All five of our servers have exactly the same problem. Is this the problem that Carl was referring to above? And if so, is there indeed a fix??? I had resigned myself that Sun just didn't know how to design an RS232 interface. Casey
viktor@cucumber.princeton.edu (Viktor Dukhovni) (03/06/89)
casey@lll-crg.llnl.gov (Casey Leedom) writes: >We use standard ascii terminals as the consoles of all our file servers. >After the systems have been up for a while, the terminals lock up and we >haven't figured out how to break them out of that mode. This happens >reliably on two 3/180s and a 3/280 running SUN OS 3.4, and two 3/280s >running SUN OS 3.5 on a whole variety of terminals. Are any of your users using programs like "setkeys" or "caps" (or anything else that uses ioctl() on "/dev/kbd")? Just a keyboard type inquiry is sufficient to hang the ascii terminal on our keyboardless server. I removed "/dev/kbd" and even commented out "device kbd3" from the kernel config file (as well as the dtop, and zs1). The servers kernel is much smaller, and no more hung ascii consoles. Hope this helps. ---Viktor Dukhovni <viktor%fine@princeton.edu>
slevy@nic.mr.net (Stuart Levy) (03/06/89)
We've seen two problems which can cause Sun RS-232 consoles to hang up. One, some as-yet-undetermined programs can open /dev/kbd or /dev/mouse or both, causing the console serial port to get set to 1200 bps, odd parity, "keyboard" line discipline (!) as indicated by stty >/dev/console and pstat -t. To fix, try "stty new 9600 >/dev/console; reset >& /dev/console". To prevent, remove or rename /dev/kbd and /dev/mouse. This suggestion showed up on this list quite a while back. Another, recently discovered by some people here, it's possible to "steal" the console device using the TIOCCONS ioctl. It caught us when people were running xterm's on our server (to an X terminal) and happened to start a console one. This is hard to prevent without a kernel mod but you can ask people not to do it.
jpt@uf.msc.umn.edu (Joseph Thomas) (03/06/89)
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
aad@stepstone.com (Anthony A. Datri) (03/06/89)
>We use standard ascii terminals as the consoles of all our file servers. >After the systems have been up for a while, the terminals lock up and we >haven't figured out how to break them out of that mode. I have it happen on an older 3/180. Hasn't happened on our 3/280 yet. Getting rid of the /dev/{mouse,kbd,fb} entries helped, but I still get it occasionally. Anthony A. Datri @SysAdmin(Stepstone Corporation) aad@stepstone.com stpstn!aad
brent@uunet.uu.net (Brent Chapman) (03/06/89)
The fix is real simple: delete /dev/fb, /dev/kbd, and /dev/mouse on
servers that don't have bitmapped consoles, keyboards, and mice. We used
to have this problem, too, and it went away after I deleted those devices
at the suggestion of our Sun FSE (Steve Cook, who does a great job for us;
all my problems with Sun support are on the software side...).
-Brent
--
Brent Chapman Capital Market Technology, Inc.
Computer Operations Manager 1995 University Ave., Suite 390
brent@capmkt.com Berkeley, CA 94704
{cogsci,lll-tis,uunet}!capmkt!brent Phone: 415/540-6400shj@ames.arc.nasa.gov (Steve Jay) (03/09/89)
The circuit to keep a Sun from halting when the console generates a break accidentally (like powering the terminal off or disconnecting the cable) was described in sun-spots v5n45, by Malcolm Harper <mkh%prg.oxford.ac.uk@nss.cs.ucl.ac.uk>, way back in Sep. 87. If our moderator is willing to send it out again to everyone rather than having interested parties retrieve it from the archives, I have appended it to the end of this message. I have never tried this circuit. Steve Jay domain: shj@ultra.com Ultra Network Technologies Internet: ultra!shj@ames.arc.nasa.gov 101 Daggett Drive uucp: ...ames!ultra!shj San Jose, CA 95134 408-922-0100 >Date: Fri, 25 Sep 87 17:23:06 bst >From: Malcolm Harper <mkh%prg.oxford.ac.uk@nss.cs.ucl.ac.uk> >Subject: Re: Sun-3 ASCII console problem (2) The circuit we use to prevent the Watchdog Reset which normally happens when the terminal is unplugged from the Sun Console port (ttya/ttyb) is as follows. To terminal To Sun pin 3 <----:-----------------------------------------------------------< pin 2 | ________ _________________ ____________ | | | | | | 2200uf 16v | :---| 470ohm |----| <- IN4002 diode |---:---| capacitor |--- pin 7 |________| |_________________| | |____________| ________ _________________ | -ve +ve | | | | | :---| 470ohm |----| <- IN4002 diode |---: | |________| |_________________| | Types of diodes and | ________ ___________________ / transistor, and values | | | b| |/c of capacitor, are not pin 2 >----+---| 4K7ohm |----| BC212L transistor | critical. | |________| |___________________|\e | _________________ \ | | | | :-----------------| IN4002 diode -> |---:-------------------> pin 3 | |_________________| | ________ _________________ | | | | | :---| 22Kohm |----| IN4002 diode -> |----------------------- pin 25 |________| |_________________| pin 7 ------------------------------------------------------------------ pin 7 We use only three wire connections, so connect pins 5, 6, 8 and 20 together at the Sun end, and appropriate control line connections at the terminal end. This circuit is permanently connected to the Sun end; any disconnection must be at the terminal end. If the terminal is unplugged, the transistor is turned on by the negative reference voltage present at pin 25 of the Sun serial port, and hence pulls pin 3 of the Sun port negative. This causes the Sun to believe there is still a terminal plugged in. Acknowledgements to Andrew Newman and Paul Williams who designed and built it.
paula@june.cs.washington.edu (Paul Allen) (03/09/89)
In article <20329@lll-winken.LLNL.GOV> casey@lll-crg.llnl.gov (Casey Leedom) writes: >erickson@frith.egr.msu.edu (Carl B. Erickson): >> Can someone point me to the fix that has been discussed for using a >> terminal as the console on a Sun 3? I believe this involved a small >> circuit of some sort. > > [Casey describes a problem with his RS232 Sun consoles hanging] >Is this the problem that Carl was referring to above? And if so, is there >indeed a fix??? I had resigned myself that Sun just didn't know how to >design an RS232 interface. I think there are two problems here. One of my 3/280's has a VT220 as its console. Once in a blue moon, I've seen it hang like Casey describes. It's never bothered me enough to spend time tracking it down. If anybody has a fix for this, I'm mildly interested. :-) I believe the circuit that Carl referred to is a kluge to prevent DTR from dropping when you unplug (or power off) the console terminal. Without such a circuit, unplugging the console results in a watchdog reset. As I recall, the circuit involved a single transistor and allowed the break key to reset the processor while preventing DTR from dropping if the terminal was accidentally unplugged or turned off. I remember seeing a posting describing this circuit, but I can't find any trace of it in my archives. Did anybody else save a copy? Paul Allen pallen@atc.boeing.com Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!ssc-vax!bcsaic!pallen
lindh@nisc.nyser.net (03/14/89)
casey@lll-crg.llnl.gov (Casey Leedom) writes: > erickson@frith.egr.msu.edu (Carl B. Erickson): > > Can someone point me to the fix that has been discussed for using a > > terminal as the console on a Sun 3? I believe this involved a small > > circuit of some sort. > > We use standard ascii terminals as the consoles of all our file servers. > After the systems have been up for a while, the terminals lock up and we > haven't figured out how to break them out of that mode. Here at the University of Hartford I run 2 Sun-3/160 Servers and we use standard VT100 terminals as consoles. No circuits needed! We have had it that war for over 3 years, just remember to change the EEPROM. But since a VT100 depends on X-ON/X-OFF it looses letters in some modes like firmware mode or running programs that do not use X-ON/X-OFF But they never hang, and we never turn them off. Also the terminal's BREAK key works as a RESET, so we don't need to get to the back of the Sun. We also use VT100's for normal terminals off the clients. -- Andrew Lindh, a student at the University of Hartford -- Computer Science West Hartford, CT -- School Switchboard (203) 243-4100 -- ask for Math/CS BITNET: LINDH@HARTFORD.bitnet INTERNET: hgcvax!evecs!lindh@nisc.nyser.net UUCP: lindh@evecs.uucp also lindh@uhasun.uucp (and root@evecs.uucp)
tr@jcricket.ctt.bellcore.com (tom reingold) (03/14/89)
In Sun-Spots-Digest Volume 7, Issue 163, message 14 of 18, On the subject of "Sun 3 console question", casey@lll-crg.llnl.gov (Casey Leedom) writes: > We use standard ascii terminals as the consoles of all our file servers. > After the systems have been up for a while, the terminals lock up and we > haven't figured out how to break them out of that mode. This happens > reliably on two 3/180s and a 3/280 running SUN OS 3.4, and two 3/280s > running SUN OS 3.5 on a whole variety of terminals. >... You should use a terminal that doesn't have a lock mode or that you can unlock with a certain key sequence. Or better yet, ground DTR on the serial link so that the Sun always thinks that the terminal is always on, even when you power it off. Tom Reingold |INTERNET: tr@ctt.bellcore.com Bell Communications Research |UUCP: bellcore!ctt!tr 444 Hoes La room 1E225 |PHONE: (201) 699-7058 [work], Piscataway, NJ 08854 | (201) 287-2345 [home]
jeff@tc.fluke.com (Jeff Stearns) (03/14/89)
casey@lll-crg.llnl.gov (Casey Leedom) writes: > [text deleted] >We use standard ascii terminals as the consoles of all our file servers. >After the systems have been up for a while, the terminals lock up and we >haven't figured out how to break them out of that mode. This happens >reliably on two 3/180s and a 3/280 running SUN OS 3.4, and two 3/280s >running SUN OS 3.5 on a whole variety of terminals.... The wedged console problem. You ain't unique. I recall two important points: - Don't ever suntools to run on the server. Some folks try to start up suntools from .login; this will of course fail on your server. In the process, it will wedge the console. FIX: Remove or rename /dev/kbd and /dev/mouse. This will force suntools to abort before it wedges your console. - Take another look at your /etc/ttys. Fire up exactly one init for your console; it should be initiated on /dev/ttya (or ttyb) instead of /dev/console. Thus your /etc/ttys should look something like: 02console 12ttya 02ttyb About those blank looks. Yeah, we get them over the phone and via email, too. -- Jeff Stearns John Fluke Mfg. Co, Inc. (206) 356-5064 jeff@tc.fluke.COM {uw-beaver,microsoft,sun}!fluke!jeff
guy@uunet.uu.net (Guy Harris) (03/16/89)
>One, some as-yet-undetermined programs can open /dev/kbd or /dev/mouse or >both, causing the console serial port to get set to 1200 bps, odd parity, >"keyboard" line discipline (!) as indicated by stty >/dev/console and >pstat -t. To fix, try "stty new 9600 >/dev/console; reset >& >/dev/console". To prevent, remove or rename /dev/kbd and /dev/mouse. Or, even better, remove the keyboard and mouse support from your kernel, as stated elsewhere. If your machine has neither a Sun keyboard nor a mouse attached to it, the keyboard and mouse support is just taking wired-down memory that might, if a page or more is freed from the kernel's grasp, be usable for other things, such as pages from files. If you have a machine with no frame buffer, Sun keyboard, nor mouse, get rid of the following (these are lines from the GENERIC configuration file): pseudo-device win128 # window devices, allow 128 windows pseudo-device dtop4 # desktops (screens), allow 4 pseudo-device ms3 # mouse support, allow 3 mice pseudo-device kb3 # keyboard support, allow 3 keyboards And yes, there is a fair bit of code this frees up; the code that, under SunView, causes the cursor to track the mouse is in the kernel, and thus requires some "pixrect" code in the kernel. Also included is code to do "event distribution" of keyboard/mouse input to SunView windows. If you're running X11, you may be able to get rid of pseudo-device win128 # window devices, allow 128 windows pseudo-device dtop4 # desktops (screens), allow 4 since cursor tracking and event distribution is done in the X server, which, as I remember, opens and reads directly from "/dev/kbd" and "/dev/mouse" (which means you will have to keep pseudo-device ms3 # mouse support, allow 3 mice pseudo-device kb3 # keyboard support, allow 3 keyboards around, although you can save a small amount of space by reducing the "3"s to "1"s).
stpeters@uunet.uu.net (03/23/89)
slevy@nic.mr.net (Stuart Levy) writes: >We've seen two problems which can cause Sun RS-232 consoles to hang up. > ... >Another, recently discovered by some people here, it's possible to "steal" >the console device using the TIOCCONS ioctl. It caught us when people >were running xterm's on our server (to an X terminal) and happened to >start a console one. This is hard to prevent without a kernel mod but you >can ask people not to do it. This can be undone by opening "/dev/console" and doing a TIOCCONS ioctl on the descriptor. Being able to move the logical console is very handy. A colleague here (Bob Darrow) used it to help debug a device driver: printf's in a driver show up on the console, wherever it may be. We've also used it to watch failing-disk error messages on a server in a noisy room down the hall from the comfort of an office. (BTW, aren't Sun serial ports RS-432 [or some such] instead of RS-232?) -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
guy@uunet.uu.net (Guy Harris) (03/24/89)
>I believe the circuit that Carl referred to is a kluge to prevent DTR from >dropping when you unplug (or power off) the console terminal. No, it's a kludge to prevent RxD from dropping and coming back up when you unplug the console terminal and plug it back in again. If RxD drops, it looks as if the machine on the other end of the wire is sending a 0 bit. If a zero bit is sent for more than some amount of time (200 ms is a figure I've heard), that's a "break condition" - that's what a "Break" key on a terminal generally produces. >Without such a circuit, unplugging the console results in a watchdog >reset. I've rarely, if ever, seen it result in that. It results in the CPU serial port chip detecting what appears to be a "break condition" on the console port, and the kernel recognizing that this was, in fact, what happened on the console port and dutifully calling the PROM monitor. Typing the "c" (for "c"ontinue) command to the PROM monitor causes it to return back to the kernel. Watchdog resets are a different kettle of worms altogether; you can't just "c" and pick up from where you left off.
david@sun.com (Vaporware Porting Group) (03/30/89)
auspex!guy@uunet.uu.net (Guy Harris) writes: >If you have a machine with no frame buffer, Sun keyboard, nor mouse, get >rid of [win, dtop, ms, and kb pseudo-devices]... Not to mention the device bwtwo*, cgtwo*, cgfour*, gpone*... lines. -
dap@uunet.uu.net (Dave Price) (04/04/89)
This conversation on sun consoles provokes me to ask a question again that
I raised before. We wish to operate a SUN with NO console, but still use
both the serial ports for other purposes NOT as consoles. E.G. in normally
a printer in one slot and a modem or X25 or another printer in the other.
I want to tell the SUN that either it has no console or that it pretends
the keyboard is there even though its not.
People turn on/off printers etc.. This must not stop the machine..
Also we do dumping type activities which means we let the machine boot
unattended overnight. There are other times when we boot unattended as
well.. These unattended boots must work.
The solutions I see are either to convince it by software that it has a
'null' keyboard, or we build a circuit that goes in the keyboard port that
'looks' like a keyboard (that never has its keys pressed).
All bright and other ideas welcomed.
Thanks Folks, Dave Price
--
UUCP : { ENGLAND or WALES }!ukc!aber-cs!dap
JANET: dap@uk.ac.aber.cs PHONE: +44 970 623111 x 3164
Post: University College of Wales, Penglais, Aberystwyth, UK, SY23 3BZ.meier@rutgers.edu (Christopher M. Meier) (04/04/89)
In article <7166@fluke.COM> jeff@tc.fluke.com (Jeff Stearns) writes: +casey@lll-crg.llnl.gov (Casey Leedom) writes: +> [text deleted] +>We use standard ascii terminals as the consoles of all our file servers. +>After the systems have been up for a while, the terminals lock up and we +>haven't figured out how to break them out of that mode.... + + - Don't ever suntools to run on the server. Some folks try to start up + suntools from .login; this will of course fail on your server. In + the process, it will wedge the console. We have several 3/160s that operate as a fileserver and suntools workstation at the same time, for over a year now with no lockup problems. Besides the packing style of the 160s and 180s, is there some other difference I am not aware of? @ Christopher M. Meier ms: MN65-2300 Honeywell Systems & Research Center @ SIP/AIT (612) 782-7191 3660 Technology Drive @ meier@SRC.Honeywell.COM !SRCSIP!meier Mpls, MN 55418 [[ I think they were referring to "headless" servers, or a server that uses /dev/ttya as its console. Some people fire up suntools straight from their .login. If they log into the console of a machine that has no bitmap display and no mouse, suntools start up anyway and promptly wedges the console. I wonder if using the emergency keyboard exit, CTRL-D and CTRL-Q, would make suntools go away in such a situation. Has anyone tried that (see the sunview(1) manual page if you don't know what I'm talking about)? --wnl ]]