Patch-ID# 100513-04
Keywords: ALM2 tty async serial printer security console pty DTR
Synopsis: SunOS 4.1.1;4.1.2;4.1.3: Jumbo tty patch
Date: Nov/09/93

SunOS release: 4.1 4.1.1 4.1.2 4.1.3 4.1.3C

Unbundled Product: 

Unbundled Release: 

Topic: Jumbo tty patch

BugId's fixed with this patch: 1048128 1069768 1008324 1040722 1070495 1060689 1064320 1104557 1068641 1056787 1061643 1012954

Changes incorporated in this version: 1068641 1056787 1061643 1012954

Architectures for this patch: sun3, sun3x, sun4, sun4c, sun4m

Patches which may conflict with this patch: 100225-02, 100194-02, 100397-01, 100188-02, 100358-01 and 100414-01.  All obsoleted patches.

Obsoleted by:

Files included with this patch: mcp_async.o 
				mti.o 
				zs_async.o 
				cons.o 
				tty_ldterm.o 
				tty_pty.o

Note: mti.o, cons.o has been integrated into 4.1.3 release, so no need
      to have patch for these 2 objects in the 4.1.3 version.

Note: The fixes for bugs 1068641, 1056787 exist in the 4.1.3 version only.

Note: The fixes for bug 1012954 exists in the 4.1.2 and 4.1.3 version only.

Problem Description: 

BugID 1012954:
SunOS does not do RTS/CTS flow control for incoming datastreams, previously
Xon/Xoff flow control had to be used, (this has been fixed for CPU (zs_async)
serial ports only).

BugID 1061643:
Synopsis:  CTE zs driver gates reception on CD during hardware flow control

BugID 1048128:
When sending output to printers, terminals, plotters etc. using
the ALM2 or zs serial ports with the xon/xoff flow control, the
output may hang intermittently.

Flow control problems exist in SunOS 4.x.  After some
extended period of time, the device would send an xoff, and data
would stop.  When data is to be resumed with an xon from the device,
the xon seems to have been dropped or ignored because data flow did
not continue.

BugID 1069768:
Sun doesn't respond on xoff at the end of a printjob

BugID 1008324
TIOCCONS can be used to re-direct console output/input away from "console"

BugID 1070495
Kernel programs using pty can get output from previous application

BugID 1040722
Process not letting go of a pty

BugID 1060689
When a port is used for dialing in and dialing out, DTR would be dropped 
and processes remain in <exiting> state with data queued for the driver.

BugID 1064320
A remote dialin session using hayes modem drops NULLs
 
BugID 1104557
In rare circumstances, attempting a TIOCSTI ioctl on a pty, when the
read side of the stream is full, can panic Bad Trap from ttycommon_qfull, 
after passing that routine a faulty pointer to the queue.

BugID 1068641, 1056787
SunOS doesn't handle ~HUPCL correctly. Typically this is seen
when one dials in to a Sun zs port, and starts a process which
is supposed to remain attached to the modem after you log off
(E.g. a dialback program). When you log off, SunOS 4.1.3 will
drop DTR. This causes the remaining process to detach from
the modem.  Note well that this *won't* be integrated into
future releases.


Install Instructions: 

NOTE: The sun4c does not use mti.o nor mcp_async.o since this architecture
      does not have VME slots and therefore cannot use the ALM-2 Asynchronous
      Line Multiplexer or Systech MTI-800/1600. So those modules are not needed. 
      sun4m does not use mti.o

E.g. install patch on sun4/4.1.2 -

Save aside the object modules from the FCS tapes as a precaution:

For sun3/sun3x 4.1/4.1.1 and sun4 4.1/4.1.1/4.1.2:
# mv /sys/`arch -k`/OBJ/zs_async.o /sys/`arch -k`/OBJ/zs_async.o.orig
# mv /sys/`arch -k`/OBJ/mcp_async.o /sys/`arch -k`/OBJ/mcp_async.o.orig
# mv /sys/`arch -k`/OBJ/mti.o /sys/`arch -k`/OBJ/mti.o.orig
# mv /sys/`arch -k`/OBJ/cons.o /sys/`arch -k`/OBJ/cons.o.orig
# mv /sys/`arch -k`/OBJ/tty_pty.o /sys/`arch -k`/OBJ/tty_pty.o.orig
# mv /sys/`arch -k`/OBJ/tty_ldterm.o /sys/`arch -k`/OBJ/tty_ldterm.o.orig

For sun4 4.1.3:
# mv /sys/`arch -k`/OBJ/zs_async.o /sys/`arch -k`/OBJ/zs_async.o.orig
# mv /sys/`arch -k`/OBJ/mcp_async.o /sys/`arch -k`/OBJ/mcp_async.o.orig
# mv /sys/`arch -k`/OBJ/tty_pty.o /sys/`arch -k`/OBJ/tty_pty.o.orig
# mv /sys/`arch -k`/OBJ/tty_ldterm.o /sys/`arch -k`/OBJ/tty_ldterm.o.orig

For sun4c 4.1/4.1.1/4.1.2:
# mv /sys/`arch -k`/OBJ/zs_async.o /sys/`arch -k`/OBJ/zs_async.o.orig
# mv /sys/`arch -k`/OBJ/cons.o /sys/`arch -k`/OBJ/cons.o.orig
# mv /sys/`arch -k`/OBJ/tty_pty.o /sys/`arch -k`/OBJ/tty_pty.o.orig
# mv /sys/`arch -k`/OBJ/tty_ldterm.o /sys/`arch -k`/OBJ/tty_ldterm.o.orig

For sun4c 4.1.3:
# mv /sys/`arch -k`/OBJ/zs_async.o /sys/`arch -k`/OBJ/zs_async.o.orig
# mv /sys/`arch -k`/OBJ/tty_pty.o /sys/`arch -k`/OBJ/tty_pty.o.orig 
# mv /sys/`arch -k`/OBJ/tty_ldterm.o /sys/`arch -k`/OBJ/tty_ldterm.o.orig
 
For sun4m 4.1.2:
# mv /sys/`arch -k`/OBJ/zs_async.o /sys/`arch -k`/OBJ/zs_async.o.orig
# mv /sys/`arch -k`/OBJ/mcp_async.o /sys/`arch -k`/OBJ/mcp_async.o.orig
# mv /sys/`arch -k`/OBJ/cons.o /sys/`arch -k`/OBJ/cons.o.orig
# mv /sys/`arch -k`/OBJ/tty_pty.o /sys/`arch -k`/OBJ/tty_pty.o.orig
# mv /sys/`arch -k`/OBJ/tty_ldterm.o /sys/`arch -k`/OBJ/tty_ldterm.o.orig

For sun4m 4.1.3:
# mv /sys/`arch -k`/OBJ/zs_async.o /sys/`arch -k`/OBJ/zs_async.o.orig
# mv /sys/`arch -k`/OBJ/mcp_async.o /sys/`arch -k`/OBJ/mcp_async.o.orig 
# mv /sys/`arch -k`/OBJ/tty_pty.o /sys/`arch -k`/OBJ/tty_pty.o.orig 
# mv /sys/`arch -k`/OBJ/tty_ldterm.o /sys/`arch -k`/OBJ/tty_ldterm.o.orig 

For sun4m 4.1.3C:
# mv /sys/`arch -k`/OBJ/zs_async.o /sys/`arch -k`/OBJ/zs_async.o.orig
# mv /sys/`arch -k`/OBJ/mcp_async.o /sys/`arch -k`/OBJ/mcp_async.o.orig
# mv /sys/`arch -k`/OBJ/tty_pty.o /sys/`arch -k`/OBJ/tty_pty.o.orig
# mv /sys/`arch -k`/OBJ/tty_ldterm.o /sys/`arch -k`/OBJ/tty_ldterm.o.orig

Install the patch files: 

From the patch directory, copy the new ".o" files from the appropriate 
`arch -k`/{OS version} directory to the OBJ directory. Example:

# cp `arch -k`/{OS version}/*.o /sys/`arch -k`/OBJ

Check that permissions and ownerships are set correctly.

Build and install a new kernel. 
Please refer to the System and Network Administration Manual for details
on how to configure and install a custom kernel.
 
