Patch-ID# 100513-05
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: Mar/04/96

Solaris Release: 1.1

SunOS Release: 4.1.3

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 1168930 1192015

Changes incorporated in this version: 1192015

Patches accumulated and obsoleted by this patch: 

Architectures for this patch: sun4, sun4c, sun4m

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

Obsoleted by:

Files included with this patch: mcp_async.o 
				zs_async.o 
				tty_ldterm.o 
				tty_pty.o
				zs_conf.c (for sun4 only)

Problem Description: 

BugID 1192015:
Panic data fault in tty driver when running an application.

BugID 1168930:
Panic data fault in zszread on ttya on Sun-4 architectures

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:
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.


Patch Installation Instructions: 

NOTE: The sun4c does not use  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.  

As root:

For sun4:
 mv /sys/`arch -k`/OBJ/zs_async.o   /sys/`arch -k`/OBJ/zs_async.o.FCS
 mv /sys/`arch -k`/OBJ/mcp_async.o  /sys/`arch -k`/OBJ/mcp_async.o.FCS
 mv /sys/`arch -k`/OBJ/tty_pty.o    /sys/`arch -k`/OBJ/tty_pty.o.FCS
 mv /sys/`arch -k`/OBJ/tty_ldterm.o /sys/`arch -k`/OBJ/tty_ldterm.o.FCS
 mv /sys/sundev/zs_conf.c           /sys/sundev/zs_conf.c.FCS

For sun4c:
 mv /sys/`arch -k`/OBJ/zs_async.o   /sys/`arch -k`/OBJ/zs_async.o.FCS
 mv /sys/`arch -k`/OBJ/tty_pty.o    /sys/`arch -k`/OBJ/tty_pty.o.FCS 
 mv /sys/`arch -k`/OBJ/tty_ldterm.o /sys/`arch -k`/OBJ/tty_ldterm.o.FCS
 
For sun4m:
 mv /sys/`arch -k`/OBJ/zs_async.o   /sys/`arch -k`/OBJ/zs_async.o.FCS
 mv /sys/`arch -k`/OBJ/mcp_async.o  /sys/`arch -k`/OBJ/mcp_async.o.FCS 
 mv /sys/`arch -k`/OBJ/tty_pty.o    /sys/`arch -k`/OBJ/tty_pty.o.FCS 
 mv /sys/`arch -k`/OBJ/tty_ldterm.o /sys/`arch -k`/OBJ/tty_ldterm.o.FCS 

Install the patched files: 

 cp `arch -k`/*.o   /sys/`arch -k`/OBJ

For sun4 only :

 cp `arch -k`/zs_conf.c   /sys/sundev

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.
 
