[ Printer Friendly Page ]
[ E-mail this Document to Someone ]
[ Was this document useful? Yes or No ]
| SRDB ID |
|
Synopsis |
|
Date |
| 14687 |
|
Stopping a BREAK when a dumb terminal console is switched off |
|
7 Jan 1997 |
Sometimes customers need to switch off or disconnect their dumb terminal
console, but do not want the machine to see this as a BREAK signal.
This is included here as it was difficult to find.
Please note that these procedures are neither recommended nor supported by Sun
for the following reasons:
If L1-A and BREAK are both disabled
- It is impossible for the customer to sync the machine should it soft-hang
- potential data loss
- impossible to generate a crash dump for analysis
- It is not possible to distinguish between a soft hang and a hard hang for
diagnostic purposes
Before letting anyone have this procedure please ensure that they are aware of
all the possible implications.
Please distribute the disclaimer comment header along with the file under all
circumstances.
Please contact your local Sun Microsystems Answer Centre for more details
******************************************************
* *
* DISCLAIMER *
* *
******************************************************
The contents of this file are intended to be read as an example.
This is not a supported product of Sun Microsystems and no hotline
calls will be accepted which directly relate to this information.
NO LIABILITY WILL BE ACCEPTED BY SUN MICROSYSTEMS FOR ANY LOSS (DIRECT
OR CONSEQUENTIAL) INCURRED IN ANY WAY BY ANY PARTY THROUGH THE USE OF
THIS INFORMATION.
NO WARRANTY OF ANY SORT IS IMPLIED OR GIVEN FOR ANY CODE DERIVED
FROM THIS INFORMATION.
*********************************************************
* *
* I SUGGEST THAT THIS IS NOT A COMPANY RECOMMENDED *
* *
* SOLUTION TO THE PROBLEM OF SYSTEM CRASHES CAUSED *
* *
* BY THE MISS USE OF A COMMAND TERMINAL, AND MUST *
* *
* ONLY BE USED AS A LAST RESORT! *
* *
*********************************************************
Recently a customer of ours requested a fix to the problem of preventing
a server from crashing when the terminal was either switched off or
disconected form the I/O lead. There doesn't appear to be a solution to the
powering down problem, because when the terminal is disconected from the
mains, the output from pin 2 (transmit) tends to swing from -12v through
0v, and goes slightly positive. This from the Sun's point of view looks
like a valid break signal, which results in the server crashing.
There is a fix, however, for the problem of preventing the server from
crashing by disconnecting the I/O lead. The solution is to solder a 2k2 ohm
resistor across pins 25 (busy-standby, not used by Sun) and pin 3 (receive).
In order to fool the "uart" on the Sun serial port into thinking that
there is a terminal permanently connected to its receive line, a -12v level
must be applied to pin 3 (receive) even when the terminal is removed. A -12v
is the quiescent RS232 condition for no data, ie the signal swings from -12v
through 0v to +12v and back again to -12v for a valid data bit transfer. Pin
25 is a programmed signal (generated by the uart) which is permanently at -7.5v
which is well within the RS232 spec. (the spec is + or - 3.5v for a minimum
signal level).
Once the server is up and running, removing the data lead from the command
terminal (assuming the mod has been carried out on the Sun end) has no effect
what so ever, the server carries on running. This was carried out a number
of times on a 3/75 with total success.
Ensure that logins are disabled on the port being used, as it should be
anyway, otherwise the system will invoke a "getty failing" / "sleeping"
message every 60 seconds. What this means is that the system has started two
gettys, the first one which was invoked by modifying the "EE" prom, location
1F for command console, the second getty by enabling logins. This causes the
second getty process to hang around not doing anything, causing a confused
system state.
If the terminal is to be powered down, the I/O lead must be disconected first.
Cheers .....
..... Phil
Date: Mon, 29 Feb 88 15:14:18 GMT
From: sunuk!ajd%suncent (Andy Dolwin - DSE UK Central Region)
To: meridian!charles
Subject: Console cable
Cc: meridian!techs
Status: R
This should help your customer ..
The fix/workaround has been around for some time:
Subject: Re: system halts when console is disconnected
Systems that don't have a full-time console are an invitation for
trouble. A Sun display on one of the servers with a window tip'ed to
the console port of each of the others is a better alternative, though
it dows make one machine rather critical.
The symptom (halting the CPU) results because a line going open looks
to the Sun CPU zs hardware the same as a BREAK. This will also happen
if the console terminal is unplugged from the AC or turned off, even
though the RS-232 cable stays connected.
There is any easy hardware workaround to this problem, originally
reported by Jim Constantine 21 months ago and resent several times
The easiest solution is for the customer to put together
a single terminal and a switch box. All he needs to do is connect
a resistor between pins 25 and 3 on each SS2. The switch would have
to be capable of switching pins 2 and 3 of each SS2 serial port to
the the customer's DTE as a null modem connection.
tty | /
port | 2 ----------------0/ 0------- 3 on sun | "
| / | 3
------x---------0/ 0------- 2 > on customers DTE
| | /
| | /
| 7 ---------------------------- 7 /
| |
| |
| | |
| | | 4.7k resistor, 1/4 watt
| | |
| |
| 25 -----x
|
NB. THE CUSTOMER MUST NOT POWER CYCLE THE HIS DTE (TERMINAL), SHOULD
HE DO SO THE SS2 WILL DETECT THE LOSS OF A SIGNAL ON PIN 3 AS
A VALID BREAK, FORCING THE SYSTEM TO COMPLETE AN UNGRACEFULL
HALT RESULTING IN POSSIBLE LOSS OF USER DATA.
-----0-----
Be sure the resistor is attached at the Sun CPU connector, not the
terminal end or switchbox end of the cable.
This fix will help ALL ttys attached to Sun CPU serial ports (ttya/b),
either for consoles or ordinary login terminals. It stops runaway
getty/login on open lines or lines where the terminal is turned off.
Beau
Along with this followup from Ed Fleschute, regarding being able to see all
the output from several terminal lines on one terminal:
A few (seven) years ago I needed to come up with a multi port switch
with the same requirements. Thanks to Beau for the input to the sun
side of the connection but if you need to see output from each system
on the console there is a workaround. You do take the chance of
multiple systems transmitting at the same time and garbling the
output..but most of the time you should get the console messages from
each. I don't remember the values of the diodes (small) or
the resistors or even the exact configuration but with some playing
it should come up.
***********************************************************************
SUN OUTPUT TO TERMINAL
tty | Diode (THEN TIE THIS LINE TOGETHER(NOT SWITCHED))
port | 2 -----------|<|---x-- on sun | | | 3
---------------- | > to customers equipment
| | /
| 7 ---------------- | /
| |
| |
| | |
| | | 4.7k resistor, 1/4 watt
| | | (ONLY NECESSARY ON ONE SYSTEM)
| |
| 25 ----------------
|
***********************************************************************
SUN INPUT FROM TERMINAL
tty |
port | 2 ---------------- on su |
| 3 ------x--------- (FROM SWITCH) > to customers equipment
| | /
| 7 ---------------- /
| |
| |
| | |
| | | 4.7k resistor, 1/4 watt
| | |
| |
| 25 -----x
|
***********************************************************************
Beau
******************************************************************
* *
* THE INFORMATION CONTAINED IN THIS FILE IS NON-CONTROLLED *
* *
* AND INCLUDES MATERIAL GLEANED FROM INFORMAL, NON-CONTROLLED *
* *
* SOURCES. IT IS INTENDED FOR ASSISTING TECHNICAL SUPPORT *
* *
* WITH INVESTIGATIONS OF TECHNICAL PROBLEMS. IF A HARDCOPY IS *
* *
* REQUIRED THEN IT SHOULD BE RETAINED IN THE NON-CONTROLLED *
* *
* BINDER OR DESTROYED AFTER USE. IT IS CATEGORICALLY NOT TO BE *
* *
* USED BY THE CUSTOMER AS REFERENCE MATERIAL IN ANY FORM. *
* *
******************************************************************
INTERNAL SUMMARY:
******************************************************
* *
* DISCLAIMER *
* *
******************************************************
The contents of this file are intended to be read as an example.
This is not a supported product of Sun Microsystems and no hotline
calls will be accepted which directly relate to this information.
NO LIABILITY WILL BE ACCEPTED BY SUN MICROSYSTEMS FOR ANY LOSS (DIRECT
OR CONSEQUENTIAL) INCURRED IN ANY WAY BY ANY PARTY THROUGH THE USE OF
THIS INFORMATION.
NO WARRANTY OF ANY SORT IS IMPLIED OR GIVEN FOR ANY CODE DERIVED
FROM THIS INFORMATION.
*********************************************************
* *
* I SUGGEST THAT THIS IS NOT A COMPANY RECOMMENDED *
* *
* SOLUTION TO THE PROBLEM OF SYSTEM CRASHES CAUSED *
* *
* BY THE MISS USE OF A COMMAND TERMINAL, AND MUST *
* *
* ONLY BE USED AS A LAST RESORT! *
* *
*********************************************************
Recently a customer of ours requested a fix to the problem of preventing
a server from crashing when the terminal was either switched off or
disconected form the I/O lead. There doesn't appear to be a solution to the
powering down problem, because when the terminal is disconected from the
mains, the output from pin 2 (transmit) tends to swing from -12v through
0v, and goes slightly positive. This from the Sun's point of view looks
like a valid break signal, which results in the server crashing.
There is a fix, however, for the problem of preventing the server from
crashing by disconnecting the I/O lead. The solution is to solder a 2k2 ohm
resistor across pins 25 (busy-standby, not used by Sun) and pin 3 (receive).
In order to fool the "uart" on the Sun serial port into thinking that
there is a terminal permanently connected to its receive line, a -12v level
must be applied to pin 3 (receive) even when the terminal is removed. A -12v
is the quiescent RS232 condition for no data, ie the signal swings from -12v
through 0v to +12v and back again to -12v for a valid data bit transfer. Pin
25 is a programmed signal (generated by the uart) which is permanently at -7.5v
which is well within the RS232 spec. (the spec is + or - 3.5v for a minimum
signal level).
Once the server is up and running, removing the data lead from the command
terminal (assuming the mod has been carried out on the Sun end) has no effect
what so ever, the server carries on running. This was carried out a number
of times on a 3/75 with total success.
Ensure that logins are disabled on the port being used, as it should be
anyway, otherwise the system will invoke a "getty failing" / "sleeping"
message every 60 seconds. What this means is that the system has started two
gettys, the first one which was invoked by modifying the "EE" prom, location
1F for command console, the second getty by enabling logins. This causes the
second getty process to hang around not doing anything, causing a confused
system state.
If the terminal is to be powered down, the I/O lead must be disconected first.
Cheers .....
..... Phil
Date: Mon, 29 Feb 88 15:14:18 GMT
From: sunuk!ajd%suncent (Andy Dolwin - DSE UK Central Region)
To: meridian!charles
Subject: Console cable
Cc: meridian!techs
Status: R
This should help your customer ..
The fix/workaround has been around for some time:
Subject: Re: system halts when console is disconnected
Systems that don't have a full-time console are an invitation for
trouble. A Sun display on one of the servers with a window tip'ed to
the console port of each of the others is a better alternative, though
it dows make one machine rather critical.
The symptom (halting the CPU) results because a line going open looks
to the Sun CPU zs hardware the same as a BREAK. This will also happen
if the console terminal is unplugged from the AC or turned off, even
though the RS-232 cable stays connected.
There is any easy hardware workaround to this problem, originally
reported by Jim Constantine 21 months ago and resent several times
The easiest solution is for the customer to put together
a single terminal and a switch box. All he needs to do is connect
a resistor between pins 25 and 3 on each SS2. The switch would have
to be capable of switching pins 2 and 3 of each SS2 serial port to
the the customer's DTE as a null modem connection.
tty | /
port | 2 ----------------0/ 0------- 3 on sun | "
| / | 3
------x---------0/ 0------- 2 > on customers DTE
| | /
| | /
| 7 ---------------------------- 7 /
| |
| |
| | |
| | | 4.7k resistor, 1/4 watt
| | |
| |
| 25 -----x
|
NB. THE CUSTOMER MUST NOT POWER CYCLE THE HIS DTE (TERMINAL), SHOULD
HE DO SO THE SS2 WILL DETECT THE LOSS OF A SIGNAL ON PIN 3 AS
A VALID BREAK, FORCING THE SYSTEM TO COMPLETE AN UNGRACEFULL
HALT RESULTING IN POSSIBLE LOSS OF USER DATA.
-----0-----
Be sure the resistor is attached at the Sun CPU connector, not the
terminal end or switchbox end of the cable.
This fix will help ALL ttys attached to Sun CPU serial ports (ttya/b),
either for consoles or ordinary login terminals. It stops runaway
getty/login on open lines or lines where the terminal is turned off.
Beau
Along with this followup from Ed Fleschute, regarding being able to see all
the output from several terminal lines on one terminal:
A few (seven) years ago I needed to come up with a multi port switch
with the same requirements. Thanks to Beau for the input to the sun
side of the connection but if you need to see output from each system
on the console there is a workaround. You do take the chance of
multiple systems transmitting at the same time and garbling the
output..but most of the time you should get the console messages from
each. I don't remember the values of the diodes (small) or
the resistors or even the exact configuration but with some playing
it should come up.
***********************************************************************
SUN OUTPUT TO TERMINAL
tty | Diode (THEN TIE THIS LINE TOGETHER(NOT SWITCHED))
port | 2 -----------|<|---x-- on sun | | | 3
---------------- | > to customers equipment
| | /
| 7 ---------------- | /
| |
| |
| | |
| | | 4.7k resistor, 1/4 watt
| | | (ONLY NECESSARY ON ONE SYSTEM)
| |
| 25 ----------------
|
***********************************************************************
SUN INPUT FROM TERMINAL
tty |
port | 2 ---------------- on su |
| 3 ------x--------- (FROM SWITCH) > to customers equipment
| | /
| 7 ---------------- /
| |
| |
| | |
| | | 4.7k resistor, 1/4 watt
| | |
| |
| 25 -----x
|
***********************************************************************
Beau
******************************************************************
* *
* THE INFORMATION CONTAINED IN THIS FILE IS NON-CONTROLLED *
* *
* AND INCLUDES MATERIAL GLEANED FROM INFORMAL, NON-CONTROLLED *
* *
* SOURCES. IT IS INTENDED FOR ASSISTING TECHNICAL SUPPORT *
* *
* WITH INVESTIGATIONS OF TECHNICAL PROBLEMS. IF A HARDCOPY IS *
* *
* REQUIRED THEN IT SHOULD BE RETAINED IN THE NON-CONTROLLED *
* *
* BINDER OR DESTROYED AFTER USE. IT IS CATEGORICALLY NOT TO BE *
* *
* USED BY THE CUSTOMER AS REFERENCE MATERIAL IN ANY FORM. *
* *
******************************************************************
Top
Sun Proprietary/Confidential: Internal Use Only
Feedback to SunSolve Team
