Technical Support Bulletin
©1984 Sun Microsystems, Inc.
Issue 1984-3 10 April 1984
3.1.	Corrections to Tech Support Bulletin Issue 1984-2.................................................1
3.2.	Attaching a modem to a Sun Workstation: a few hints —.............................2
3.3.	RS-232 control signal dropping when /dev/console opened..............................4
3.4.	Using unsupported modems "with uucp............................................................................................5
3.5.	Remote install of release 1.0: error in System Manager's Manual ............................6
3.6.	dump uses incorrect default tape length ........................................................................................6
3.7.	Sample scripts for routine back-up dumps on server .....................................................7
3.8.	Limitations on Sun UART performance —............................................—	S
3.9.	Problem 'with distribution lists in /utr/lib/aliases................................................9
3.10.. Accounting must be configured in kernel...........................................................................9
3.] I. 4014 emulation on Sun-2 ......................—.........................................................................................9
3.J 2. Cau't access SCSI disk vrhiie tape is in use.....................................................................................10
3.13.	Customer error in device driver causes rmzllcc panic...........................................................10
3.14.	''Lost cursor" bug fixed in PR CM monitor...................................................................11
5.15.	Running laige programs on the San-2..............................................................................................12
3.16.	New mandatory devices in kernel.........................................._............................................12
3.17.	Combining SCSI and Xylogics controllers on one system.............................13
3.18.	Can't turn off output parity on Sun ttys----------------------------------------------------------------13
This Bulletin is edited by Martin Rattner. Any comments or corrections may be sent to him at M/S 3-10, Sun Microsystems, Inc., 2550 Garcia Ave., Mountain View, CA 94043 or sfnd uucp mail to sun!sundial!pranalysis. Customers who have technical questions about topics in the Bulletin should call Sun Technical Support.
Technical Support Bulletin
Sun Microsystems, Inc.
Issue 1984-3 10 April 1984
3.1) Corrections to Tech Support Bulletin Issue 1084-2.
Description:
The following errors were found in Issue 1984-2 of the Technical Support Bulletin (17 February 1984):
Item number 2.2 (What to do when tip says "all ports busy") says that the permissions on tip's output device should be rw-rw-rw- (666). Normally the mode of the device should be 600 and the owner should be uucp. In addition, here are a couple of other things to check if you get the "all ports busy" message from tip:
a)	Make sure there is no getty enabled for the port that tip is trying to use, i.e. that UNIX isn't trying to log someone in on that port. You can check this with "ps ax", or check that the corresponding line in /etc/ttys begins with a "0". If the line in /etc/ttys begins with a "1", you must edit it, then type "kill -1 1" to get rid of the getty.
Note: this does not apply to the Systech multiplexor board, which permits both dial-in and dial-out on the same line. This will be supported beginning with Release 1.1.
b)	If you still get the "all ports busy" message, the problem may be that the modem attached to ftp's'output port has gotten into a weird state. Try powering the modem off and back on again.
Another problem with pre-1.1 versions of tip is that it may sometimes give the "connected" message, even though its serial port is nonexistent or has the wrong ownership or permissions. In this case, no characters are transmitted or received, although tip is still alive and responds to tilde escapes. To fix this, you should try the same remedies as for the "all ports busy" message.
In the newest version of tip (Release 1.1 and later), this problem has been fixed and the error messages improved. For example, when the serial line has the wrong permissions or ownership you will see:
myhost% tip otherhost
tip: /dev/ttyb: Permission denied
all ports busy
myhost%
UNIX is a trademark of Beli Laboratories. Multibus is a registered trademark of Intel Corporation. Ethernet is a registered trademark of Xerox Corporation. DEC and VAX are registered trademarks of Digital Equipment Corporation. Smartmodem is a trademark of Hayes Microcomputer Products, Inc. Ventel is a trademark of Ventel, Inc. Sun Microsystems and Sun Workstation are registered trademarks of Sun Microsystems, Inc. Sun-2, Sun-2/xxx, Deskside, SunStation, SunCore, SunWin-dows, and DVMA are trademarks of Sun Microsystems, Inc.
©1984 Sun Microsystems, Inc.
-1-
10 April 1984
Issue 1984-3
Technical Support Bulletin
See Also:
Item 2.2, "What to do when tip says 'all ports busy'" in Tech Support Bulletin Issue 1984-2.
Description:
At the end of item number 2.20 (More miscellaneous information about "tar") was the following example of the use of the -C option of the tar command:
cd /usr/fred/bin
tar cvbf 126 /dev/rstO * -C /usr/bill/l.O * -C /usr/nancy/bin *
This example is incorrect because the asterisks will be expanded by the shell in the current working directory before being passed to the tar. Even if the asterisks were escaped or quoted so that they were passed to tar, the example would still be incorrect because tar does not recognize the "*" as a meta-character. This example would work correctly if the asterisks were replaced with dots:
tar cvbf 126 /dev/rstO . -C /usr/bill/l.O . -C /usr/nancy/bin .
The resulting tape would contain all of the files in directories /usr/bill/l.O, /usr/nancy/bin, and the current working directory. Their names would be stored on the tar tape in the form ./namel, ./name2, and so on.
See Also:
tar(l) manual page.
Item 2.20, "More miscellaneous information about 'tar'" in Tech Support Bulletin Issue 1984-2.
3.2) Attaching a modem to a Sun Workstation: a few hints Description:
This item provides a few miscellaneous tips for attaching modems to Suns. It is not meant to be an exhaustive discussions of RS-232 serial lines, modems, or data communication. For more details, consult a datacomm book (such as one of those referenced below) or talk to someone knowledgeable in data communications. We will try to supply additional information in future issues of the Bulletin.
Now that we've got the disclaimers out of the way, the following points may be of some use:
a)	In systems with the Sun-1 or Sun-1.5 processor board, connect the modem to serial port a (/dev/ttya). Only port a has modem control signals on these CPU boards. Since port a is wired as DCE, you will need a null modem cable, which is constructed as follows:
Pins 2 and 3 are crossed. Pins 4 and 5 are crossed. Pins 6 and 20 are crossed. Pin 7 is wired straight through.
The term "pins 2 and 3 are crosscd" means that pin 2 at one end of the cable is wired through to pin 3 at the other er»d and vice-versa.
b)	In systems with a Sun-2 processor board, connect the modem to any available serial port /dev/ttyz, where x is a, b, sO si, s2, s3, tO, tl, t2, or t3. Ports s[0-3] and t[0-3] are only available on Models 120/170 with SCSI board(s). AH of these ports are wired as
DTE, so do not use a null modem cable to connect to a modem; your cable should be
10 April 1984
-2-
©1984 Sun Microsystems, Inc.
Technic-al Support Bulletin
Issue 1984-3
•wired straight through on pins 2, 3, 4, 5, 6, 7, and 20.
c)	If the port to which the modem is attached is to be used for dialing out to other machines, then you should disable logins on that line. Examine the file /etc/ttys and make sure that the first character on the line with the name of that serial port is a '0' (disable logins) rather than a '1' (enable logins). For example, the file might look like this:
12console
02ttya
02ttyb
if logins are enabled on the console only. If you have to edit /etc/ttys, you must then type the command "kill -1 1" to make your changes take effect.
Note: beginning with Release 1.1 it is possible to dial-out and dial-in on the same serial line. This feature will be documented in a future issue of the "Tech Support Bulletin" and will supersede the preceding paragraph as well as paragraphs (d) and (e) below.
d)	If the port to which the modem is attached is to be used for dialing in to the Sun, then you should enable logins by editing /etc/ttys and changing the first character of the corresponding line from s0' to '!'. As above, you should type "klii -1 to make the change effective.
e)	For a dial-in port, you should reconfigure the kernel for hardware carrier detect rather than software. This is determined in the kernel configuration file by the flags value specified for the device corresponding to the serial port. For example, in the generic kernel configuration file /sys/conf/GENERIC in a system running Release 1.0 or later (Sun-2 processor board) you will find a line for "device 2s0" which is the UART device for serial ports a and b. The default flagt value on this line is "3" (binary 11), each 1 bit indicating software carrier for the corresponding port a and b. If port a is being used for dial-in, change the flags value to "2" (binary 10), indicating hardware carrier on port a. If port b is the dial-in, the flagt value should be "1" (binary 01). If both ports are dial-in, the flags field should be "0".
On a Model 120 or 170 with SCSI board, the first two SCSI serial ports (/dev/ttysO and 1) appear in the configuration file as device zs2; the next two SCSI serial ports (/dev/ttys2 and 3) are device zs3; a second SCSI board, if present, would contain zs4 and zs5, corresponding to devices /dev/ttytO through 4. On a Sun-1.5 system, the device name for serial ports a and b is "suO", but the flags field has the same meaning as for isO and should be edited as described above.
Complete instructions for reconfiguring the kernel are found in the System Manager's Manual for Releases 1.0 and later. In Release 0.4 and earlier, the file /sys/conf/README contains abbreviated instructions.
If you've reconfigured the flags to zero as described above, and now want to use the port for attaching a terminal or other device which does not assert DTR, you can either reconfigure the kernel again or you can use a "cheater cable" which loops-back DSR (pin 6) to DTR (pin 20). See also Item 3.3 below, "RS-232 control signal dropping when /dev/console opened" for more information on cheater cables.
f)	The UNIX commands most commonly used in conjunction with a modem are tip (for logging into a remote host machine) and uucp (for file transfer and remote command execution on another UNIX host). Uucp is discussed in more detail, including installation instructions, in the System Manager's Manual for Releases 1.0 and later; uucp and
tip are described in the UNIX mamia! pages cited below.
©1984 Sun Microsystems, Inc.
-3-
10 April 1984
Issue 1984-3
Technical Support Bulletin
See Also:
Various general references on data communications, for example: Data Communications Handbook, Signetics Corporation, 1981. Basics of Data Communications, McGraw Hill, 1976.
Technical Aspects of Data Communications, John E. McNamara, DEC Press, 1977.
tip(l), uucp(l), uux(l), zs(4), su(4), remote(5) maDnal pages.
System Manager's Manual for the Sun Workstation:
Sections on uucp installation, uucp implementation description, kernel configuration.
3.3) RS-232 control signal dropping when /dev/conso!e opened
Applies to: Sun-2 systems using ttya or ttyb as system console Description:
Several customers using a terminal as console on ttya or b have encountered a problem of their terminal going dead just after the "root on ..." message at the point where mini-UNIX should print the "# " prompt. The system still responds to BREAK by aborting, though.
The problem only occurs when the customer is using a "complete" RS-232 cable and a terminal that cares about signals other than transmit/receive/ground. The problem is caused by UNIX re-initializing the UARTs when it first opens /dev/console, disrupting the modem control signals which have already been initialized by the PROM monitor.
No fix is planned for Release 1.1, but the customer can circumvent the problem by configuring his terminal not to use the modem control lines, or by using a "cheater cable". An appropriate (and probably overkill) cheater cable would look like this:
Sun 2	__Terminal
(DTE)	(DTE)
Required:
7	7	Signal Ground
Null modem (signal reversal) portion:
2	—►	3	(Transmit to Receive)
3	—►	2	(Receive to Transmit)
Cheater Portion (on each side):
6 -loopback- 20 -loopback- 8 (DTR to DSR and CD asserted)
4	-loopback- 5 (CTS to RTS)
The theory of the cheater portion is that devices looking for either DTR or DSR will be asserting the other, and that a loopback will make them happy. The same is true for CTS and RTS. CD is just asserted, for particularly picky devices.
One customer with an ADDS Viewpoint terminal found that it was sufficient to loopback 20 (DTR) to 5 (CTS) on the terminal end of the cable. This is a very strange cable, because if his terminal is looking for CTS (Clear To Send, pin 5) it's probably asserting RTS (Request To Send, pin 4) which would suggest looping-back 4 to 5 as indicated in the table above. It so happens that the terminal is also asserting DTR, so the cable works anyhow.
To diagnose problems with RS-232 lines it is helpful to have the manual for the terminal
and a "breakout- box". A breakout box plugs into the RS-232 cable, providing a patch
10 April 1984
-4-
©1984 Sun Microsystems, Inc.
Technic-al Support Bulletin
Issue 1984-3
panel which allows you to connect any pin to any other pin(s); it often will contain LEDs which display the presence or absence of a signal on each pin.
Note that most of the above applies equally well to printers, modems, or other RS-xxx devices for your Sun.
3.4) Using unsupported modems with uucp Description:
In Sun UNIX systems through Release 1.1, uucp only contains auto-dialer support for a handful of DEC modems and the Ventel MD212 plus. Similarly, tip only auto-dials the Ventel. Many of our customers have asked if they can use other vendor's modems, such as Vadic, Hayes Smartmodem, or U.S. Robotics. The answer is a qualified "yes".
In the case of tip, the user should put an entry for the modem in /etc/remote as for a hardwire line, for example:
hardwire:dv=/dev/ttyb:br#1200:eI=*C"S"Q*U*D:ie=%$:oe=*D:
Notice that there are no Udu" or "at" fields (which would indicate an auto-dialer). Then "tip hardwire" connects you to the modem itself, after which you type in whatever commands are necessary to make the modem dial the remote host. Auto-dial support for additional modems may be built into tip in future releases.
In the case of uucp, it is possible to auto-dial the modem by putting an appropriate entry into uucp's L.sys file. L.sys contains one line for each system which can be called by the local uucp, including login information for the remote host. The trick for dialing an unsupported modem is to combine the modem's dial-out protocol with the login protocol for the remote machine.
One drawback to this approach is that you can't mix different dialer types on the same system, since the dialer type is wired into the L.sys entry for the called system. For example, . you couldn't have both a Ventel and a Hayes and use both for dialing out.
The U.S. Robotics modem is advertised to be Hayes Smartmodem compatible. Early versions (manufactured a few months ago) were not compatible, but U.S. Robotics has new ROMs which fix this. You either can check that you have the compatible ROMs (it's supposedly a free upgrade if you don't) or you can modify the Smartmodem entry below until
it works. You can use "uucico -rl -sSYSTEMNAME -x9" to debug--x9 causes the entire
dialer interaction to be printed.
The following L.sys entry was tested on a Model 150 with a Hayes Smartmodem. The names, phone number, and password have been changed for security. This entry would dial a host named "host" using phone number 555-1212 and login as "Umyhost" with password "mypassword".
host Any ttyb 1200 ttyb "" AT\r\c OK ATDT5551212\r\c \ CONNECT-A/\c-CONNECT-A/\c-CONNECT-A/\c-CONNECT \ EOT ogin:-EOT-lc<rin: Umyhost ssword: mypassword
See Also:
tip(l), uucp(l), uux(l) manual pages.
System Manager's Manual for the Sun Workstation:
Sections on uucp installation and uucp implementation description.
©1984 Sun Microsystems, Inc.
-7-	10 April 1984
Issue 1984-3
Technical Support Bulletin
3.5) Remote install of release 1.0: error in System Manager's Manual
Applies to: Release 1.0. Description:
There is an error in Chapter 5 of the Release 1.0 System Manager's Manual, "Installing UNIX on Systems Without Tape Support". At the end of section 5.6, the manual has described the loading of the mini-UNIX file system onto the disk. The manual erroneously says that when the copy completes, it returns control to the bootstrap program:
Copy completed Boot:
and then the manual tells you to boot mini-UNIX immediately. Actually, when the copy is complete, it returns control to the PROM monitor:
Copy completed >
At this point, you must load the boot program again:
> fc ud (acfvcf_ouarc««)booi
[ . . . messages . . . )
Boot:
You can then proceed with section 5.7, "Booting the Mini UNIX System".
3.6) dump uses incorrect default tape length
Applies to: Releases 0.3, 0.4, 1.0 Description:
In the 1.0 release, as well as in earlier releases, dump calculates tape length incorrectly for both 1/2" and 1/4" tapes. The problem is seen when you dump a partition that is too iarge to fit on one tape with default tape lengths. Before dump reaches where it would normally stop, it finds end-of-tape and returns an error message.
With 1/2" tapes, the length of the tape (which is specified with the "s" option) should be set to 2100 feet, rather than the default length of 2400 feet (10 1/2" reel):
dump Ous 2100 /dev/rxyOg
With 1/4" tapes, the "c" option is normally used to tell the system you are dumping to a cartridge tape. This option sets both tape length and density, either of which may be changed by setting them explicitly. To avoid going past end-of-tape, the length of the tape should be set to 1000 feet. It is also recommended that you use the "b" option to change the default block size to an optimal size:
dump Oucsbf 1000 128 /dev/rarO /dev/rxyOg
Note that the order of the arguments must match the order of the options. These bugs are fixed in the 1.1 release. See Also:
dump(8) manual page.
Item 2.19, "Use large buffer size with Archive tape drive" in Tech Support Bulletin Issue 1984-2.
10 April 1984
-6-
©1984 Sun Microsystems, Inc.
Technic-al Support Bulletin
Issue 1984-3
3.7) Sample scripts for routine back-up dumps on server
Applies to: Network disk servers. Description:
' The shell scripts appearing below are used at Sun for doing routine back-up dumps of the file systems on one of our disk servers. These can be adapted for use on other Sun servers. Note that these scripts assume the existence of the raw ndl devices (/dev/rndl*).
The first script, dump.ndfull, does a full dump of a specified list of "ndl" partitions. These are typically the file systems of the server's diskless clients. The dump files are written consecutively onto one reel of tape. The system administrator first uses the df command to determine the sizes of the file systems to be dumped. Then the arguments to dump.ndfull
are chosen so that all of the selected file systems will fit on one tape. ###############
#	dump.ndfull ###############
for i in $* do
J-.1-
uai<e
echo dumping ndi$i
/etc/dump Ouf /dev/nrmt8 /dev/rndl$i done
echo DONE unloading tape mt offline
After mounting the tape, this script is invoked, for example, as: dump.ndfull 0 14
assuming in this case that these three file systems /dev/ndlO, /dev/ndll, and /dev/ndl4 will fit onto a tape reel.
.The next script, dump.ndincl, performs a full dump of the server's root file system, and level 9 incremental dumps of three other server file systems: partitions e, f, and g. Partition g contains /pub, while partitions e and f are locally defined. These dumps are written consecutively on a single reel of tape. This script does not take arguments like the previous one, because on this machine we have determined that these dumps will fit on a single tape reel.
##############
#	dump.ndincl ##############
/etc/dump Ouf /dev/nrmtO /dev/rxyOa /etc/dump 9uf /dev/nrmtO /dev/rxyOe /etc/dump 9uf /dev/nrmtO /dev/rxyOf /etc/dump 9uf /dev/nrmtO /dev/rxyOg mt offline
We do not have a script for doing full dumps of the server's file systems. Since these file systems tend to be quite large, the system administrator has to determine manually which file system(s) will fit on a reel of tape, so a script would not save much effort in this case.
The third script, dump.ndinc2, does level 9 incremental dumps of a predetermined list of ndl partitions, 0 through 4. This script also takes no arguments, since we have determined empirically that these dumps will all fit on one reel of tape.
©1984 Sun Microsystems, Inc.
-7-
10 April 1984
Issue 1984-3
Technical Support Bulletin
##############
# dump.ndinc2 ##############
for i in 0 1 2 3 4
do
date
echo dumping ndl$i
/etc/dump 9uf /dev/nrmt.0 /dev/rndl$i done
echo ALL DONE unloading tape mt offline
See Also:
Item 1.5, "Warning: backing up diskless clients (ndl partitions)" in Tech Support Bulletin Issue 1984-1.
3.8) Limitations on Sun UART performance
Applies to: Releases 0.3, 0.4, and 1.0 Description:
The serial line UARTs on systems running release 1.0 or earlier cannot reliably accept continuous input data at speeds greater than 1200 baud.
The Sun-2 CPU board uses the Zilog 8350 serial chip which can buffer four bytes at a time. When a byte comes in, the 8350 issues an interrupt which the CPU must service to capture that byte. There are sections of code in the kernel which raise the interrupt level to insure they are not interrupted while,executing. This causes serial line interrupt servicing to be postponed. Certain sections of the operating system can postpone servicing the serial lines long enough for all the buffers of the serial chip to get filled. This will cause the next byte received to be lost because there is no place to put it. When this happens, a "Silo Overflow" message will appear on the console. Although data is lost, the silo overflow is not fatal to UNIX.
This situation is somewhat improved in the 1.1 release. The ports on the CPU and SCSI boards are capable of output up to 19.2 kbaud and input up to 9600 baud. In the output case, it is unlikely that the system will be able to deliver output at that pace continually. In practice this means that output to terminals will slow as the system load increases. Sustained input at 9600 baud on one CPU port is possible without character loss if the system is otherwise idle. Sustained input at 9600 baud to the SCSI ports or to more than one port simultaneously will result in dropped characters. When this happens, a "silo overflow" console message will appear.
Sun makes no guarantees of performance of any Sun product when used as a multi-user timesharing machine. On a Model 120, the software in theory permits connection of two terminals to the CPU board, four to the first SCSI board, and four to the second SCSI board. In practice, if timesharing is desired a better approach is to use the Systech multiplexor board, which is a DMA device and is likely to place less of a load on the system. Sun does not guarantee any level of input or output performance for the Systech multiplexor board, although experience suggests that it is better than any of the UARTs and better than the Central Data B1018/B1043 octal serial board.
10 April 1984
-8-
©1984 Sun Microsystems, Inc.
Technic-al Support Bulletin
Issue 1984-3
3.8) Problem with distribution lists in fusrf lib/aliases
Applies to: Release 1.0 Description:
In Release 1.0, to avoid the necessity of running newaliases, sendmail was compiled without DBM support for the alias file. This turned up a bug in sendmail which does not occur under DBM: each alias line is stored in sendmail's internal symbol table with an unexpected trailing newline. This causes various problems, especially when the message is queued, since the newline causes a blank line in the saved "qf" file, which causes the message to be rejected next time the queue is run.
This problem can be circumvented by putting a comma at the end of each line containing aliases. This causes the newline to be skipped over as whitespace rather than being appended to the last name.
This problem is fixed in 1.1. It would not show up anyhow, since we are once again compiling sendmail with DBM enabled in the released version. This requires the system administrator to run the newaliases command whenever the aliases file is changed.
Note: If you added the extra commas to your aliases file as suggested above, you can leave them in your 1.1 system if you wish — they will not hurt anything.
See Also:
"Sendmail Installation and Operation Guide"
in System Manager's Manual, Tutorials section.
3.10)	Accounting must be configured in kernel Description:
If system accounting appears not to work, make sure that you have not reconfigured your kernel with the "options SYSACCT" and "pseudo-device sysacct" lines removed from the • kernel configuration file.
See Also:
acct(2), acct(5), sa(8) manual pages.
System Manager's Manual sections on kernel configuration.
3.11)	4014 emulation on Sun-2
Applies to: Sun-2/l00U, Sun-2/150U, Models 120 and 170. Description:
AH of the Sun-2 upgrades for Models 100U and 150U which are shipped with software Release 1.0 have Rev L monitor PROMs. These PROMs do not support the 4014 terminal emulation which was present in earlier (Sun 1.5) PROM versions and which was part of the product specification for Sun-2 upgrades for Models 100U and 150U. 4014 emulation for Models 100U/150U is once again included in the Rev N PROMs, which are to accompany software Release 1.1.
Models 120 and 170 do not support 4014 emulation under either Release 1.0 or 1.1.
©1984 Sun Microsystems, Inc.
-9-
10 April 1984
Issue 1984-3
Technical Support Bulletin
See Also:
Item 1.20, "No 4014 emulation in Rev. L PROMs" in Tech Support Bulletin Issue 1984-1.
3.12) Can't access SCSI disk while tape is in use
Applies to: Models 120, 170. Description:
On the Sun, the SCSI disk doesn't support the SCSI disconnect/reconnect function. The result is that the disk can't be accessed when tape is in use, even when it's just rewinding. The symptom is that the system may temporarily "freeze" while the tape is in motion, even if the process accessing the tape is running in background.
3.13) Customer error in device driver causes rmalloc panic
Applies to: 1.0 release and above Description:
Since it is not possible to dynamically locate devices in Multibus memory space, the kernel at boot time needs to know the Multibus addresses at which various devices are mapped. Sun uses certain portions of Multibus memory space for its own purposes, including DVMA space, the Sun frame buffer, etc., but other portions are available for customer use with their own boards and drivers.
Each Multibus driver defines entries for a set of routines as well as an array of types which are acceptable to it. These are used at boot time by the configuration program.
There is a structure in /usr/include/sundev/mbvar.h which looks like this:
It is critical that your driver use this structure. If this structure is not available, and in particular, device memory address and amount of memory space needed are not supplied, the resource map handling routines, which test for a size < 0, will cause the boot to fail
struct mb_driver {
int	(*mdr_probeX);
int	(*mdr_slaveX);
int	(*mdr_attach)();
int	(*mdr_goX);
int	(*mdr_doneX);
int	(*mdr_intr)();
ujong	*mdr_ioaddr;
u_long	* m dr_m addr;
int	mdr_size;
char	*mdr_dname;
struct	mb_device **mdr_dinfo;
char	*mdr_cname;
struct	mb_ctlr **mdr_cinfo;
short	mdr_flags;
struct	mb_driver *mdr_link;
*	see if a driver is really there */
*	see if a slave is there */
*	setup driver for a slave */
*	routine to start transfer */
*	routine to finish transfer */
*	interrupt routine »/
*	device csr addresses */
*	device memory address * /
*	amount of memory space needed */
*	name of a device */
*	backpointers to mbdinit structs */
*	name of a controller *j
*	backpointers to mbcinit structs */
*	want exclusive use of Multibus */
*	interrupt routine linked list */
10 April 1984
-10-
©1984 Sun Microsystems, Inc.
Technic-al Support Bulletin
Issue 1984-3
with a "panic: rmalloc" message.
The size needed is related to your device's particular specifications. Sun now has a Multibus Memory Map showing available address ranges, which may be requested through , Technical Support.
See Also:
"Writing Device Drivers for the Sun Workstation" in System Internals Manual.
3.14) "Lost cursor" bug fixed in PROM monitor Description:
Many customers have reported the problem that in full-screen terminal emulation the cursor sometimes disappears. This occurred when using cat or more on a binary file. A bug in the PROM monitor causcd the cursor to disappear when an ANSI escape sequence was produced while in graphics mode. This bug has been fixed in the Rev N PROMs, which will reside on Model 100U and 15GU CPU boards beginning with release 1.1.
If you have an earlier PROM release, such as Rev J, Rev K, or Rev L, you can restore the cursor by typing the following at a shell prompt:
echo 'ESCfc'
where ESC means you should type the ESC key. You may also put an alias in your .cshrc file, similar to
alias fixcursor 'echo "BSC^" '
Then, at the shell prompt, typing
fixcursor
will restore the cursor.
• Remember that UNIX echoes the escape character as "*{". There are other escape sequences available. For example, echo *ESC[q'
will reverse the workstation monitor to white type on a dark background. This could be stored in your .cshrc file as
alias dark'echo "ESCfq"'
Similarly, echo lESC[p' and alias light 'echo "ESCf' will restore the monitor to black type on a light background.
See Also:
Item 1.9, "Useful escape sequences for full-screen terminal emulation"
in Tech Support Bulletin Issue 1984-1. (Release 0.4 and earlier): Programmer's Reference Manual for the Sun Workstation
Section 5.1, "ANSI Terminal Emulation". (Release 1.0 and later): System Manager's Manual
"Sun Workstation Monitor" Appendix, "ANSI Terminal Emulation" section.
©1984 Sun Microsystems, Inc.	-11-	10 April 1984
Issue 1984-3
Technical Support Bulletin
3.15) Running large programs on the Sun-2
Applies to: 1.0, 1.1 releases Description:
In Release 1.0, the maximum permitted program data size was computed as a function of the swap partition size. Maximum text size (code size), however, had a fixed limit of 1.5 megabytes. In Release 1.1, maximum text size and data size are now both dependent on swap size.
\Digression\ You can find out the size of a program by typing the command "size program". This gives you the size of text (code), data (initialized data), and bss (uninitialized data) of the program. The swap partition is usually partition b on a system with local disk (/dev/xyOb, for example) or partition ndl on a diskless client (/dev/ndl). You can find the sizes of local disk partitions with the /etc/dkinfo command. Partitions for diskless clients are configured in /etc/ndAocal on the server. [End digression].
The text and data limits depend on Low much swap space is configured, as follows:
Maximum Program Size in Release 1.1
Swan snacc Unit of allocation Max Text
<	6 Meg
<	8 Meg < 12 Meg <16 Meg > 16 Meg
256 sectors 512 sectors 1024 sectors 2048 sectors 4096 sectors
1530K 3072K 6144K 6144K 6144K
Uov
iUUA L/UbU
1776K 3312K 6128K 11248K 16320K
The stack segment size is initially limited to 512K bytes by the system but may be as large as the data segment size if it is increased with the setrlimit system call. At no time may the sum of the text, data, and stack segment sizes be greater than 16320K.
Warning: All these numbers are based only on calculation. They have not yet been confirmed by experiment.
See Also:
size(l), nd(8C) manual pages.
3.16) New mandatory devices in kernel
Applies to: 1.1 only Description:
There is a problem with bwone and cgone devices such that they may, due to user program error, start generating interrupts forever. This essentially renders UNIX unusable (an endless stream of "Interrupt not serviced" messages to the console).
Including bwone or cgone devices in the configuration file for a kernel will load the appropriate software for suppressing this problem. Such lines from a 1.1 GENERIC file look like this:
10 April 1984
-12-
©1984 Sun Microsystems, Inc.
Technical Support Bulletin
Issue 1984-3
device cgoneO at mbO csr OxeBOOO priority 3 device bwoncO at mbO csr OxcOOOO priority 3
Unfortunately, even if these drivers are omitted from the kernel, the system may still appear to operate correctly because of older software that opens /dev/console instead of /dev/fb, /dev/bwone, etc. If a customer encounters the "Interrupt not serviced" problem, make sure that the appropriate device drivers are configured for whichever graphics boards are present in the system.
3.17) Combining SCSI and Xylogics controllers on one system
Applies to: Early production of Models 120 and 170 Description:
Putting a Xylogics controller or other bus master controller on a Model 120 or 170 with an early version SCSI controller sometimes caused problems. The earliest versions of the SCSI controller did not handle bus arbitration correctly, which resulted in bad block transfers to the SCSI disk when there were more than two bus masters on the Multibus (the CPU and the SCSI board are bus masters). ECO 656 corrects this problem. Anyone with a SCSI controller experiencing this problem should contact Field Support and request the necessary ECO.
Note that this configuration (SCSI plus Xylogics in a 120) is not a released, supported configuration; it currently exists only in a few in-house, demo, and test machines.
There is a way to circumvent the problem pending installation of the ECO. Located on the lower left side of the Sun-2 CPU board sure four jumper options. CBRQ is the second jumper on the left (J701). To run the system with more than two bus masters and a SCSI controller without the ECO, the CBRQ jumper should be installed. This forces all bus mas-• ters to release the Multibus after each cycle they use. While circumventing the SCSI problem, insertion of the CBRQ jumper will incur a slight performance penalty. After solving the SCSI arbitration problem with ECO 656, the temporarily inserted CBRQ jumper can be removed.
3.18) Can't turn off output parity on Sun ttys
Applies to: Releases 0.3, 0.4, and 1.0 Description:
Prior to Release 1.1, output parity cannot be disabled on the Sun on-board serial lines without setting the line to RAW mode. Printers that interpret the most significant bit, bit 8, for graphics characters must have parity disabled. Unfortunately, RAW mode also disables *S/*Q flow control, which is required by many of these printers. The affected devices are dev/tty{a,b,s0,sl,s2,s3,t0,tl,t2,t3}.
This has been fixed for the 1.1 release. You can turn off parity and get 8 bits out without using RAW mode.
For Releases 1.0 and earlier, you can use an output filter to control output parity without disabling flow control. Copies of suitable filters were recently mailed to all home office and field technical support staff. These should be freely distributed to customers who need
©1984 Sun Microsystems, Inc.
-13-
Issue 1984-3 them.
Technical Support Bulletin
10 April 1984
-14-
©1984 Sun Microsystems, Inc.