My original query was:
>I am using a VT220 attached to /dev/ttya as the console of our Sun 4/280
>running SunOS 4.1. If you hit the BREAK key on the VT220 or unplug the
>VT220 or turn the VT220 off, the Sun halts and enters PROM console mode
>(the ">" prompt).
>
>I consider this a bug; it causes occasional accidental halts. I would be
>interested in hearing how others have solved this problem. Specifically,
>how do you disable this action, and having done so how do you enter
>console mode when you really want to?
Several dozen people replied, offering some very useful information. I am
grateful to all.
The action of the BREAK key is intentional. Sun designed it as the
equivalent to the action of the L1-A keystroke on Sun keyboards. It
serves the useful - in fact essential - function of letting you regain
control of a hung machine. Having hit BREAK or L1-A, you can enter a
"c" command, and the machine will continue execution normally.
I agree that one needs to be able to regain control of a hung machine,
but I disagree with using the BREAK function to do it. It is too easy
to hit accidently. The L1-A used on Sun keyboards, the control-P used
on VAXen, and the control-alt-delete used on the PC are all
intentionally difficult to execute by accident. Moreover since
disconnecting the VT220 or turning it off looks to the Sun like a
BREAK, we cannot even reroute console cables in the machine room
without shutting the system down - something that is not a problem on
any of the other systems.
So what to do about accidental BREAKs and the need to recable?
The solutions that people offered fell into one of the following
categories. All prevent accidental halts to some degree.
DON'T DO IT!
Put the console in a safe place where BREAK won't be hit. Post signs
warning of dire consequences that will befall anyone who touches it.
This solution is as strong as human will power. It allows intentional
halts, but it does not allow recabling.
GUARD THE KEY
Make a small shield to cover the BREAK key. This allows intentional
halts but does not allow recabling.
DISABLE THE KEY MECHANICALLY
Remove the key or perform other violence to the keyboard in order to make
it impossible to actuate the key. This prevents intentional halts and
does not allow recabling.
DISABLE THE KEY VIA SETUP MODE
The VT200 keyboard setup menu lets you disable the BREAK key logically.
This allows intentional halts (by reversing the process) but does not
allow recabling.
THE SOLDERING IRON SOLUTION
If you tie a 4.7K resistor between pins 3 and 25 of the ttya port, you
electrically prevent a BREAK signal either from the key or from
disconnecting or powering down the terminal. This prevents intentional
halts except by removing the resistor but does allow recabling.
PATCH THE KERNEL
You can use adb to patch the kernel routine zsa_xsint() so that BREAKs
from whatever source do not cause a halt. See the SunWorld article sited
below for details. This prevents you from dealing with a hung machine,
but it does allow recabling.
Several people referred me to two very useful articles by Hal Stern
(stern@sunne.East.Sun.COM). One is the /sys.admin column in the May, 1992,
issue of SunWorld (Vol. 5, No. 5). Stern discusses these questions and
other aspects of consoles. I recommend the article highly.
An earlier article by Stern was mentioned as being available on the net
under the name serial.ps. This article contains valuable tutorials on
RS-232, cabling, configuring modems, UUCP, a bibliography(!), and several
appendices. It generates 20 pages. ARCHIE found 4 sources for the file.
Since all were in Europe, I have put the file in pub/sun/serial.ps on
dartvax.dartmouth.edu [which is not a VAX any more; it is in fact the
subject of my query].
Oh, by the way, I plan to use the 4.7K resistor solution. In the unlikely
event of a hang, we'll flip off the resistor and hit BREAK.
Steve Campbell
Dartmouth College
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:45 CDT