This is an ancient post with no relevance to modern systems.
The answer is different for Unix and Xenix, but much of the information is the same, so it's been grouped together here. We will deal with the common information first, and the specific details for Xenix and Unix.
By default, Xenix and Unix set the 16550's trigger level to 14. This means that once fourteen characters have been received, the 16550 will generate an interrupt (it will also generate an interrupt if the buffer is not full but serial data flow has stopped, so the system doesn't always have to wait until the trigger level is reached). This give the system two character times in which to begin to clear the buffer; at high speed on a highly loaded system, this may not be enough, and you may still lose characters even though you have a 16550. On the other hand, this value should generally be set as high as possible to reduce the number of interrupts generated; servicing an interrupt is quite costly in terms of CPU time.
There is an array in the kernel called sio_fifoctl. It is a 16-byte array with control values for different minor numbers. To find which array element will be used for a particular serial port, AND the minor number of the port with 0x0F (for example, /dev/tty2A has a minor number of 136 and /dev/tty2a of 8; either one ANDed with 0x0F yields 8, so sio_fifoctl controls this port).
There are four different values you may wish to use for the entries in sio_fifoctl. A value of 0x0F sets the trigger value to 1; 0x4F sets it to 4; 0x8F sets it to 8; 0xCF sets it to 14 (these values are determined by the 16550 itself, not by SCO, and other values will not set the trigger level to intermediate values).
In Xenix, this parameter is set by patching the disk image of the kernel (/xenix) using adb (the info on how to find adb is elsewhere in this FAQ). The following is a sample adb session to change the trigger level of /dev/tty2A to 8 from 14 (the line numbers in parentheses are for the explanation below); the asterisks are adb's prompt and should not be typed in:
Line 1 makes a backup, and line 2 runs adb in write mode. Line 3 tells adb to print the current value of sio_fifoctl. Line 4 is adb's reply, which includes two bytes from this array (the rightmost one is the value for sio_fifoctl, and the leftmost is for sio_fifoctl). You must look at these carefully, as one half will have to be changed while the other will have to be left alone. In line 5, we write 0xCF8F into this location; note that the value for sio_fifoctl is left unchanged at 0xCF. Line 6 is adb's reply giving the old and new values. Line 7 quits adb.
For Unix, there is a table at the end of the text file /etc/conf/pack.d/sio/space.c which gives the same array. It is formatted in the same manner (to find the appropriate value, AND the minor device number with 0x0F).
If you run Unix, check the man page for the sar command to see if you have the -g option to check for serial I/O overruns. If so, try running it. If you see overruns, this indicates that your trigger level is set too high and the system doesn't have adequate time to service the 16550. The cure is to turn the trigger level down one notch and try again.
The information for Xenix in this answer is taken from the comp.unix.xenix.sco FAQ, maintained by Chip Rosenthal. The copyright for that document reads:
This collection is Copyright 1992-1994, Unicom Systems
Development, Inc. All rights reserved. Permission granted to
reproduce and distribute this document provided this notice remains
intact and any changes to the document are clearly marked. We have
tried to review all information, but cannot guarantee it for any
particular purpose. We do not offer any warranties or
representations, nor do we accept any liability for any damage
resulting from the use or misuse of information or procedures in
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? (Brian Kernighan)