From: fas@geminix.in-berlin.de (FAS Support Account)
Subject: v27i070: FAS-2.11.0 - asynch serial driver for System V, Part04/08
References: <1.750471074.20539@gw.home.vix.com>
Sender: unix-sources-moderator@gw.home.vix.com
Approved: vixie@gw.home.vix.com
Submitted-By: fas@geminix.in-berlin.de (FAS Support Account)
Posting-Number: Volume 27, Issue 70
Archive-Name: fas-2.11.0/part04
#!/bin/sh
# this is fas211pl0.04 (part 4 of a multipart archive)
# do not concatenate these parts, unpack them in order with /bin/sh
# file fas.7.cat continued
#
if test ! -r _shar_seq_.tmp; then
echo 'Please unpack part 1 first!'
exit 1
fi
(read Scheck
if test "$Scheck" != 4; then
echo Please unpack part "$Scheck" next!
exit 1
else
exit 0
fi
) < _shar_seq_.tmp || exit 1
if test ! -f _shar_wnt_.tmp; then
echo 'x - still skipping fas.7.cat'
else
echo 'x - continuing file fas.7.cat'
sed 's/^X//' << 'SHAR_EOF' >> 'fas.7.cat' &&
X control CCCCTTTTSSSS will go low and therefore the output gets
X blocked. If at this time there are still characters in the
X output buffer the last process closing this port can't ter-
X minate until the buffer has drained. But as DDDDSSSSRRRR will also
X go low if you switch off the device the blocking of the out-
X put will be prevented.
X
X In short: Hardware output handshake is only used if the
X connected device sets DDDDSSSSRRRR high, that is, the device is
X switched on and is ready. So make sure that you keep this
X in mind when you make serial cables and when you configure
X your serial devices. DDDDSSSSRRRR must be on if you want CCCCTTTTSSSS
X handshake.
X
X The other advantage of this CCCCTTTTSSSS/DDDDSSSSRRRR mechanismn is that you
X can still connect "dumb" serial devices to an _F_A_S hardware
X handshake port using a minimal 3-wire cable. As an uncon-
X nected DDDDSSSSRRRR line is automatically low, hardware output
X handshake is disabled, which is just what you want in this
X case. However, it's safer to use a minor device number of 0000
X + device # for 3-wire cables (see section CCCCAAAABBBBLLLLIIIINNNNGGGG).
X
X The CLOCAL flag doesn't affect this mode.
X
X Note: If you use a minor device number where hardware
X handshake is disabled (see ``First mode'' below) you
X can, if you have SCO UNIX 3.2.4, enable full duplex
X hardware flow control by setting the CRTSFL _t_e_r_m_i_o(M)
X flag. This works, however, only if neither
X CTSFLOW/RTSFLOW nor CLOCAL are set.
X
X In SCO UNIX 3.2.4.2 the meaning of CTSFLOW/RTSFLOW has
X
X
X Rev. Release 2.11.0 Page 7
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X changed. These flags enable full duplex hardware flow
X control. For backward compatibility there is the
X ORTSFL flag which enables, when set together with
X CTSFLOW and/or RTSFLOW, half duplex flow control.
X These flags only work if CLOCAL is nnnnooootttt set.
X
X Half duplex mode
X There are actually three half duplex modes selected by the
X minor device number:
X
X First mode
X If the RTSFLOW _t_e_r_m_i_o(M) flag is set and the CLOCAL
X flag is nnnnooootttt set the RRRRTTTTSSSS line is used to signal the
X connected device that there is data in the output
X buffer. As long as there is output data to come the
X RRRRTTTTSSSS line stays high. If the output buffer has drained
X RRRRTTTTSSSS drops to low until there is more data to be sent
X to the connected device.
X
X If the CTSFLOW _t_e_r_m_i_o(M) flag is set and the CLOCAL
X flag is nnnnooootttt set the CCCCTTTTSSSS line is used to control the
X output character flow. This works as in full duplex
X mode.
X
X If neither CTSFLOW nor RTSFLOW are set hardware flow
X control is disabled. But see the description of the
X CRTSFL/ORTSFL _t_e_r_m_i_o(M) flags at the end of the sec-
X tion FFFFuuuullllllll dddduuuupppplllleeeexxxx mmmmooooddddeeee.
X
X Note: Setting the CTSFLOW and RTSFLOW flags (and
X CRTSFL/ORTSFL, if available) only applies to SCO
X UNIX and Xenix. To my knowledge, other UNIX
X flavors don't have these flags. For them,
X hardware flow control is always disabled in this
X mode.
X
X Second mode
X This mode overrides the RTSFLOW, CTSFLOW, CRTSFL and
X ORTSFL flags and works as if the CTSFLOW flag is set
X permanently (all UNIX flavors). The CLOCAL flag
X doesn't affect this mode.
X
X Third mode
X This mode overrides the RTSFLOW, CTSFLOW, CRTSFL and
X ORTSFL flags and works as if both the RTSFLOW and
X CTSFLOW flags (in SCO UNIX prior to 3.2.4.2 and SCO
X Xenix) are set permanently (all UNIX flavors). The
X CLOCAL flag doesn't affect this mode.
X
X Note: Under SCO UNIX prior to 3.2.4.2 and Xenix the
X _t_e_r_m_i_o(M) RTSFLOW flag is intended for half duplex
X hardware flow control devices. Setting it when the
X connected device does ffffuuuullllllll duplex hardware flow
X
X
X Rev. Release 2.11.0 Page 8
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X control is a configuration error! The RRRRTTTTSSSS signalling
X for half duplex devices has a completely different
X meaning than for full duplex devices. So you should
X either set only CTSFLOW (or CRTSFL, if available), or
X you should select hardware flow control via the minor
X device number. If you set RTSFLOW for full duplex
X hardware flow control devices it is likely that the
X port won't work. This is in line with SCO's _s_i_o
X driver implementation.
X
X Direct control
X On UNIX flavors where the RTS_TOG _i_o_c_t_l(2|S) command is
X available the hardware handshake output (RRRRTTTTSSSS by default) can
X be set under program control. An _i_o_c_t_l(2|S) argument of 0000
X sets the output to low and an argument of 1111 sets it to high.
X However, this only works if the hardware handshake modes as
X well as _V_P/_i_x DOS mode are disabled. If one of these modes
X is enabled _F_A_S needs the hardware handshake output for its
X own flow control.
X
X On the other hand, even if one of these modes is in use and
X _F_A_S gets an RTS_TOG command, the state of the handware
X handshake output that this command tries to set is stored
X and the output is set to the state of the last RTS_TOG com-
X mand as soon as both hardware handshake mode and DOS mode
X are disabled.
X
X In other words, _F_A_S doesn't ignore the RTS_TOG command if
X hardware handshake modes or DOS mode are set but rather
X overrides the hardware handshake output with the appropriate
X state computed internally.
X
X _V_P/_i_x SUPPORT
X _F_A_S allows DOS programs running under _V_P/_i_x to access serial
X ports. You simply need to modify your personal _V_P/_i_x confi-
X guration file (_v_p_i_x._c_n_f) to tell the DOS emulator which _F_A_S
X devices to use for COM1 (or COM1MOUSE) and COM2.
X
X Note that _V_P/_i_x opens these devices at startup time, so you
X better make sure that the desired devices aren't used by
X other processes when you start _V_P/_i_x as _V_P/_i_x wants to use
X them exclusively.
X
X There are some special features with the handling of the RRRRTTTTSSSS
X and DDDDTTTTRRRR lines you should know about. If your DOS program
X asserts the DDDDTTTTRRRR line this will actually cause action on the
X modem enable line you configured in _s_p_a_c_e._c. Likewise, RRRRTTTTSSSS
X asserts the half duplex hardware handshake line configured
X in _s_p_a_c_e._c.
X
X If the used _F_A_S device has full duplex hardware handshake
X enabled, asserting RRRRTTTTSSSS from DOS actually stops the character
X flow from _F_A_S to _V_P/_i_x. This prevents input buffers of
X
X
X Rev. Release 2.11.0 Page 9
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X interrupt driven DOS programs from overflowing. _F_A_S, on the
X other hand, uses its hardware handshake to prevent an over-
X flow of its own input buffer. Therefore, you can use DOS
X telecommunication programs even at high baud rates without
X losing characters, provided your DOS programs are configured
X to use full duplex RRRRTTTTSSSS/CCCCTTTTSSSS flow control.
X
X All this virtual handling has the advantage that the DOS
X program doesn't need to know certain details about your
X actual port setup. Reading the modem status register, on
X the other hand, doesn't cause any translation of the regis-
X ter value.
X
X To enable _V_P/_i_x support, the HAVE_VPIX define in _f_a_s._h has
X to be uncommented.
X
X MODIFYING A PORT'S DEFAULT BEHAVIOUR
X There are some flags that you can set in the _f_a_s__m_o_d_i_f_y[]
X array (_s_p_a_c_e._c) for each port independently. You have to
X relink the kernel before these flags have any effect. Here
X is a description:
X
X NNNNOOOO____TTTTEEEESSSSTTTT
X If for some reason a UART doesn't pass the functional-
X lity test _F_A_S makes at boot time you can override the
X test result and use this port, anyway. However, you
X do this on your own risk. Don't be surprised if ports
X get hung or your machine crashes. I won't support _F_A_S
X installations where this flag is used. It is intended
X as a last resort.
X
X There is one exception to this, though. If the
X NNNNOOOO____TTTTEEEESSSSTTTT flag is already set in the sample config files
X for certain serial cards and provided that these sam-
X ple files are part of the original _F_A_S distribution,
X you won't lose my support because in this case I've
X tested the respective product myself and decided that
X it is safe to use the NNNNOOOO____TTTTEEEESSSSTTTT flag with it.
X
X NNNNOOOO____HHHHUUUUPPPP____PPPPRRRROOOOTTTTEEEECCCCTTTT
X Normally, with modem control enabled, after the car-
X rier is lost the carrier is ignored and assumed to be
X missing even if the physical carrier line is asserted
X again.
X
X Additionally, as the device can't accept a call in
X this state, anyway, the modem enable line is set to
X low so that the modem won't answer calls. This
X prevents users from getting the shell of a previous
X user in case that the shell doesn't react to SIGHUP
X for some reason. So the modem port is dead until this
X situation is dealt with.
X
X
X
X Rev. Release 2.11.0 Page 10
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X This adds some security to modem ports. However, if
X this feature breaks one of your applications for some
X reason, just set NNNNOOOO____HHHHUUUUPPPP____PPPPRRRROOOOTTTTEEEECCCCTTTT and the hangup protec-
X tion is disabled for this port.
X
X NNNNOOOO____OOOOVVVVEEEERRRRRRRRUUUUNNNN
X The device has some sort of receiver overrun protec-
X tion. For instance, it may be used with certain
X internal modems that use a _N_S_1_6_x_5_0 UART emulation and
X have their own receiver buffer. This flag only
X affects the position of the device in the interrupt
X users chain, that is, because the device can't overrun
X it is serviced only after all devices that don't have
X an overrun protection have been taken care of.
X
X NNNNEEEEWWWW____CCCCTTTTSSSSRRRRTTTTSSSS
X Some "intelligent" serial cards from third party ven-
X dors have the meaning of the RTSFLOW _t_e_r_m_i_o(M) flag
X redefined. It is used, together with CTSFLOW, to
X enable full duplex hardware flow control, whereas SCO
X introduced RTSFLOW for the more traditional half
X duplex hardware flow control that is implemented in
X their _s_i_o driver. By default, _F_A_S emulates the _s_i_o
X driver for compatibility reasons.
X
X However, if you like to use CTSFLOW/RTSFLOW for full
X duplex hardware flow control in a way that is compati-
X ble with the above mentioned "intelligent" cards, you
X can do this by setting NNNNEEEEWWWW____CCCCTTTTSSSSRRRRTTTTSSSS. Also,
X CTSFLOW/RTSFLOW are no longer affected by CLOCAL if
X NNNNEEEEWWWW____CCCCTTTTSSSSRRRRTTTTSSSS is set. In this mode CTSFLOW enables the
X output flow control and RTSFLOW enables the input flow
X control. Both flags are independent from each other.
X
X Note that under SCO UNIX 3.2.4.2 the CTSFLOW/RTSFLOW
X flags have changed their meaning in that they enable
X full duplex hardware flow control.
X
X These flags are defined in _f_a_s._h. For example, if you want
X to use the meaning of RTSFLOW that is compatible to some of
X the "intelligent" serial cards you would write
X
X NEW_CTSRTS
X
X at the appropriate position in _f_a_s__m_o_d_i_f_y[]. If you addi-
X tionally want to skip the test routine for this port you
X would write
X
X NO_TEST | NEW_CTSRTS
X
X UART FIFO CONTROL
X In order to control the operating modes of UARTs that have
X built-in FIFOs you can select the desired mode for each port
X
X
X Rev. Release 2.11.0 Page 11
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X independently by modifying the _f_a_s__f_i_f_o__c_t_l[] array
X (_s_p_a_c_e._c). You have to relink the kernel before these
X changes have any effect. There are a number of predefined,
X mutually exclusive symbols available:
X
X FFFFIIIIFFFFOOOO____DDDDEEEEFFFFAAAAUUUULLLLTTTT
X All UART types with FIFOs.
X The FIFOs are enabled and in case that an _N_S_1_6_5_5_0_A was
X detected, the receiver FIFO trigger level is set to 4
X or 8 characters (depending on the UNIX flavour, see
X the description of LOW_INT_LAT in section
X TTTTRRRROOOOUUUUBBBBLLLLEEEE----SSSSHHHHOOOOOOOOTTTTIIIINNNNGGGG, subsection CCCChhhhaaaarrrraaaacccctttteeeerrrr lllloooossssssss).
X
X FFFFIIIIFFFFOOOO____OOOOFFFFFFFF
X All UART types with FIFOs.
X The FIFOs are disabled and the UART works in the
X _N_S_1_6_4_5_0 compatible mode.
X
X FFFFIIIIFFFFOOOO____EEEEMMMMUUUULLLL____NNNNSSSS11116666444455550000
X All UART types with FIFOs.
X The FIFOs are enabled and in case that an _N_S_1_6_5_5_0_A was
X detected, the receiver FIFO trigger level is set to 1
X character. The transmitter FIFO is filled with only 1
X character per transmitter interrupt. This emulates
X the _N_S_1_6_4_5_0 UART and additionally gives you the over-
X run protection provided by the receiver FIFO.
X
X FFFFIIIIFFFFOOOO____PPPPOOOOIIIINNNNTTTTEEEERRRR____DDDDEEEEVVVV
X _N_S_1_6_5_5_0_A, only.
X The FIFOs are enabled and the receiver FIFO trigger
X level is set to 1 character. This should be used for
X pointer devices like mice or trackballs because it
X prevents the short receiver FIFO timeout delay that
X could lead to jerky pointer movement.
X
X FFFFIIIIFFFFOOOO____TTTTRRRRIIIIGGGGGGGGEEEERRRR____1111
X _N_S_1_6_5_5_0_A, only.
X The FIFOs are enabled and the receiver FIFO trigger
X level is set to 1 character.
X
X FFFFIIIIFFFFOOOO____TTTTRRRRIIIIGGGGGGGGEEEERRRR____4444
X _N_S_1_6_5_5_0_A, only.
X The FIFOs are enabled and the receiver FIFO trigger
X level is set to 4 characters.
X
X FFFFIIIIFFFFOOOO____TTTTRRRRIIIIGGGGGGGGEEEERRRR____8888
X _N_S_1_6_5_5_0_A, only.
X The FIFOs are enabled and the receiver FIFO trigger
X level is set to 8 characters.
X
X FFFFIIIIFFFFOOOO____TTTTRRRRIIIIGGGGGGGGEEEERRRR____11114444
X _N_S_1_6_5_5_0_A, only.
X The FIFOs are enabled and the receiver FIFO trigger
X
X
X Rev. Release 2.11.0 Page 12
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X level is set to 14 characters.
X
X Note that you can set these values even if the respective
X UART doesn't have FIFOs, in which case they are ignored. If
X you later upgrade to a UART with FIFOs the FIFO control
X values automatically become active without having to build a
X new kernel.
X
X SELECTING ALTERNATIVE BAUD RATES
X The UNIX _t_e_r_m_i_o(7|M) interface only supports baud rates of
X up to 38400 bps. However, with the advent of V32bis and
X faster modems with compression ratios of up to 4:1 (V.42bis)
X this upper baud rate boundary isn't adequate anymore. Baud
X rates of 57600 or even 115200 are necessary to make full use
X of these modems.
X
X _F_A_S provides these high baud rates even though the
X _t_e_r_m_i_o(7|M) interface doesn't know them. To make this work,
X _F_A_S has one or more baud rate tables in _s_p_a_c_e._c
X (_f_a_s__b_a_u_d[][]) which contain the baud rate base and the 15
X baud rates that correspond to B50 to B38400. Arbitrary baud
X rates can be assigned to these baud rate symbols. Baud rate
X table 0 by default contains the standard baud rates that
X coincide with the standard _t_e_r_m_i_o(7|M) baud rates. Table 1
X contains the same values for the first 13 baud rates. How-
X ever, B19200 is assigned to a baudrate of 57600 and B38400
X is assigned to 115200 bps. These values are the default in
X the _F_A_S distribution, and you can change these tables to
X whatever values you need.
X
X Note, however, that the baud rate base in this table has to
X be dividable by all 15 baud rate values without remainder,
X or at least with a very small remainder. Otherwise there
X would be a noticeable deviation between the requested and
X the actually used baud rate. It helps a little that _F_A_S
X rounds the result of this division to minimize the devia-
X tion.
X
X Note also that it isn't advisable to use the B50 and B75
X symbols for 57600 and 115200 bps. This has two reasons.
X
X In the worst case (SCO UNIX and Xenix) _F_A_S transfers the
X characters between its ring buffers and the UNIX CLIST
X buffers only every 17 milliseconds. This optimizes perfor-
X mance and reduces the CPU load. Now, there are certain baud
X rate dependent threshold values that limit the number of
X characters the CLIST buffers can hold. This is to reduce
X the drain time of the output buffers. So, at low baud rates
X these thresholds are very low, and because _F_A_S transfers
X characters only 60 times a second, the maximum throughput
X for transmitted characters is threshold * 60. One can
X easily calculate that the threshold has to be at least 192
X characters for 115200 bps (11520 cps). A sufficient
X
X
X Rev. Release 2.11.0 Page 13
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X threshold is only provided for baud rates >= B9600.
X
X Because the threshold table in the UNIX kernel is a global
X object that is also used by other drivers, _F_A_S can't simply
X override these values. So max. throughput is only possible
X with baud rate table positions of B9600 or better.
X
X The other reason not to use B50 etc. is that programs like
X _v_i and _e_m_a_c_s make their behaviour dependent on the baud rate
X of the tty they run on. And this behaviour clearly wouldn't
X fit baud rates like 57600 and 115200.
X
X Therefore, even if it looks tempting to use baud rate sym-
X bols that aren't in use anymore today (like B50 and B75),
X just don't do it. It won't work very well.
X
X So we have two or more baud rate tables in _s_p_a_c_e._c, one for
X the standard _t_e_r_m_i_o(7|M) assignment and the others for
X non-standard baud rates. You can select which table to use
X for each port by simply putting the table number in the
X _f_a_s__b_t__s_e_l_e_c_t[] array in _s_p_a_c_e._c. Provided you use the
X default baud rate table values you would use a table selec-
X tor value of 0000 for ports that should have the standard
X _t_e_r_m_i_o(7|M) baud rate assignment, and a value of 1111 to have
X 57600 and 115200 bps available instead of 19200 and 38400
X bps.
X
X Note: At speeds of more than 38400 bps it is likely that
X even an _N_S_1_6_5_5_0_A will lose incoming characters because
X in many UNIX flavors the worst case interrupt latency
X is rather high. It has to be <= 1 ms or you are in
X trouble. This problem is caused by the UNIX kernel
X design. _F_A_S can't do anything about it. ISC UNIX
X 3.0, for instance, on a 486/33 works fine at this
X speed. On the other hand, ISC UNIX 2.x can't handle
X it. You may want to look at the description of
X LOW_INT_LAT in section TTTTRRRROOOOUUUUBBBBLLLLEEEE----SSSSHHHHOOOOOOOOTTTTIIIINNNNGGGG, subsection
X CCCChhhhaaaarrrraaaacccctttteeeerrrr lllloooossssssss.
X
X Additionally to having higher baud rates available, this
X table based baud rate selection mechanism can be used to
X support serial cards that don't use the standard 1.8432 MHz
X oscillator frequency. For instance, if you have a card that
X is equiped with a 3.6864 MHz oscillator you would have the
X additional baud rates of 57600, 76800, 96000 and 115200
X available (you shouldn't use more than 115200 because that
X loads the CPU too much). Just enter the baud rate base
X (3686400 / 16 = 230400) and the 15 baud rates into one of
X the baud rate tables in _f_a_s__b_a_u_d[][] and select the respec-
X tive table in _f_a_s__b_t__s_e_l_e_c_t[].
X
X Note that _V_P/_i_x programs which use serial ports will select
X wrong baud rates on ports that are driven by a non-standard
X
X
X Rev. Release 2.11.0 Page 14
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X oscillator, unless they know about the different oscillator
X frequency.
X
X Note also that whatever baud rate is actually used, the UNIX
X application programs still know only the standard
X _t_e_r_m_i_o(7|M) baud rates. So don't wonder if _s_t_t_y shows you
X 38400 bps on a port that in fact runs at 115200 bps. _F_A_S
X hides the real baud rate from the rest of the UNIX kernel
X and the application programs. That's the only way these
X additional baud rates can work at all.
X
X CABLING
X Cabling depends on the serial card and the device that you
X want to connect.
X
X Connecting a modem
X The most common case is connecting a modem to a computer.
X "Dumb"-port cards in an IBM-AT compatible computer usually
X act as a DTE device and have a male connector while modems
X are DCE devices and have a female connector. So all you
X need is an extension cable with a male connector on one side
X and a female connector on the other side.
X
X The cable has to have wires for at least the signals TTTTDDDD, RRRRDDDD,
X RRRRTTTTSSSS, CCCCTTTTSSSS, DDDDSSSSRRRR, DDDDCCCCDDDD, DDDDTTTTRRRR, RRRRIIII and GGGGNNNNDDDD. On a D-Sub 25 RS232C
X connector these are the pin numbers 2222, 3333, 4444, 5555, 6666, 8888, 22220000, 22222222
X and 7777, respectively, and the wireing scheme has to be
X "straight through", that is, none of the wires are crossed.
X For the cabling of less common devices please look at the
X manuals for further details.
X
X In all cases, though, use shielded cables wherever you can,
X especially with high baud rates! Shielded cables are better
X protected against electromagnetic interferences and there-
X fore help to prevent data corruption during transmission.
X Also, make the cables as short as possible.
X
X However, don't leave unused input lines (CCCCTTTTSSSS, DDDDCCCCDDDD, DDDDSSSSRRRR, RRRRIIII)
X open! Due to crosstalking from other lines these input
X lines might change their logic level, resulting in all sorts
X of problems (bad throughput, blocked character output etc.).
X Therefore, you should connect any unused input line to GGGGNNNNDDDD
X (pin 7777 on the D-Sub 25 RS232C connector).
X
X Additionally, you should use the proper operating mode (via
X the minor device number) for your application, for instance,
X if the connected device doesn't have hardware flow control,
X you should use a mode where hardware flow control is dis-
X abled. The same is true for modem control.
X
X Connecting two UNIX systems
X If you want to connect two UNIX systems (both using _F_A_S) via
X a null modem cable, and if you want to run a _g_e_t_t_y on both
X
X
X Rev. Release 2.11.0 Page 15
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X ends you need to modify the _s_p_a_c_e._c file to prevent both
X _g_e_t_t_ys from chatting with each other, wasting valuable CPU
X time.
X
X Remove the EEEEIIII____DDDDTTTTRRRR macro for the desired port from the ini-
X tializer part of the _f_a_s__m_o_d_e_m[] array. This will cause DDDDTTTTRRRR
X to be asserted only on dialout. Therefore, the _g_e_t_t_y will
X become alive only if a dialout on the other side is in pro-
X gress.
X
X Also, replace the HHHHOOOO____CCCCTTTTSSSS____OOOONNNN____DDDDSSSSRRRR macro in the _f_a_s__f_l_o_w[]
X array with HHHHOOOO____CCCCTTTTSSSS. This will cause CCCCTTTTSSSS to be used for
X hardware output flow control regardless of the state of DDDDSSSSRRRR.
X
X The required null modem cable needs to cross TTTTDDDD/RRRRDDDD, RRRRTTTTSSSS/CCCCTTTTSSSS
X and DDDDTTTTRRRR/DDDDCCCCDDDD. The following diagram shows the wireing scheme
X for DTE D-Sub 25 connectors on both sides.
X
X D-Sub 25 System A System B
X ======== ======== ========
X 2 TD --------\ /-------- TD
X X
X 3 RD --------/ \-------- RD
X
X 4 RTS --------\ /-------- RTS
X X
X 5 CTS --------/ \-------- CTS
X
X 20 DTR --------\ /-------- DTR
X X
X 8 DCD --------/ \-------- DCD
X
X 6 DSR --\ /-- DSR
X >-\ /-<
X 22 RI --/ \ / \-- RI
X >---<
X 7 GND ------/ \------ GND
X
X Note that DDDDSSSSRRRR and RRRRIIII are directly connected to GGGGNNNNDDDD on each
X side so that they can't catch electromagnetic interferences.
X
X Connecting a mouse
X Another caveat is connecting a mouse or some other pointer
X device to an _F_A_S port. There are many mice on the market
X that don't handle the modem and hardware flow control lines
X in a proper way. Therefore, they should be connected to a
X port with a minor device number of 0000 + device #. This dis-
X ables any modem or hardware flow control and prevents the
X device from locking up under certain circumstances.
X
X You may also want to refer to the section UUUUAAAARRRRTTTT FFFFIIIIFFFFOOOO CCCCOOOONNNNTTTTRRRROOOOLLLL
X if your mouse is connected to a port driven by a UART with
X FIFOs.
X
X
X Rev. Release 2.11.0 Page 16
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X MODEM SETUP
X _F_A_S has certain requirements for the modem setup that must
X be met in order to avoid problems during operation.
X
X If modem control should be used (carrier sensing with DDDDCCCCDDDD
X and hangup control with DDDDTTTTRRRR), you need to program the modem
X in the following way:
X
X DDDDTTTTRRRR high->low causes the modem to drop the connection
X (hangup) and resets the modem to its power-on default
X setup. Additionally, when the modem is in answer mode
X (for dialin) it shouldn't answer calls if DDDDTTTTRRRR is low.
X
X DDDDCCCCDDDD is set high when there is a carrier detected or
X rather, to be precise, when the connection procedure
X between the two modems is finished and the modems are
X ready to transfer user data. DDDDCCCCDDDD is dropped to low if
X the modem senses that the connection to the other modem
X is lost (e.g. no carrier).
X
X If hardware flow control should be used (CCCCTTTTSSSS for output
X direction and RRRRTTTTSSSS for input direction), you need this setup:
X
X RRRRTTTTSSSS signals to the modem whether the DTE (e.g. the com-
X puter) can accept data or not. High means the DTE can
X accept data while low means that the modem should stop
X sending data to the DTE.
X
X CCCCTTTTSSSS signals to the DTE whether the modem can accept data
X or not. High means the modem can accept data while low
X means that the DTE should stop sending data.
X
X DDDDSSSSRRRR is always on. This line acts as a gate for the CCCCTTTTSSSS
X signal. _F_A_S ignores CCCCTTTTSSSS if DDDDSSSSRRRR is low, so DDDDSSSSRRRR has to be
X always high to make sure that _F_A_S always pays attention
X to CCCCTTTTSSSS.
X
X Note that the behaviour of RRRRTTTTSSSS and CCCCTTTTSSSS (as described
X above) is called bidirectional or full duplex hardware
X flow control. Don't select half duplex hardware flow
X control with modern highspeed modems!
X
X By default, _F_A_S uses both modem and hardware flow control so
X you have to make sure that in your modem DDDDTTTTRRRR, DDDDCCCCDDDD, RRRRTTTTSSSS, CCCCTTTTSSSS
X and DDDDSSSSRRRR work the way described above.
X
X If your modem can't handle modem and/or hardware flow con-
X trol you have to use a different minor device number for
X this device that disables the respective feature. Otherwise
X lockups and malfunctions could occure. Look at section
X OOOOPPPPEEEERRRRAAAATTTTIIIINNNNGGGG MMMMOOOODDDDEEEESSSS AAAANNNNDDDD MMMMIIIINNNNOOOORRRR DDDDEEEEVVVVIIIICCCCEEEE NNNNUUUUMMMMBBBBEEEERRRRSSSS for a description
X of possible operating modes (minor device numbers).
X
X
X
X Rev. Release 2.11.0 Page 17
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X Here are a few additional hints for the modem setup:
X
X If you program the modem to answer calls (dialin mode)
X you should make sure that the modem escape code character
X which allows online access to the modem command mode is
X disabled. Otherwise, the escape code sequence typed in
X at the remote side is echoed by the local computer and
X causes the local modem to switch to command mode as well.
X At this stage, only a hangup will reactivate the modem
X port. Modems with an AT command set disable the escape
X code with
X
X AT S2=128
X
X If you want to dial in and out on the same modem port the
X modem's power-on default setup should be tailored for
X dialin mode (incl. auto answer eeeennnnaaaabbbblllleeee). When a dialout
X takes place the dialout application provides the neces-
X sary modem commands to switch the modem to dialout mode
X (incl. auto answer ddddiiiissssaaaabbbblllleeee) and then does the actual
X dialout. After the dialout is finished _F_A_S makes sure
X that DDDDTTTTRRRR is dropped for a second which resets the modem
X to its power-on defaults so that the modem is in dialin
X mode, again.
X
X TROUBLE-SHOOTING
X There are a number of know problems that you might encounter
X when you are using _F_A_S. They are usually caused either by a
X configuration error or by limitations of the hard- and
X software environment _F_A_S has to work in.
X
X Character loss
X A common problem with fast serial data transmission is that
X the receiving side occasionally drops characters. The rea-
X son for this lies in the ancient UART devices used in many
X 286/386 systems: the _8_2_5_0 (not supported by _F_A_S) and the
X _N_S_1_6_4_5_0.
X
X They have only one receiver character buffer. This implies
X that the operating system must read a character from this
X buffer before the next one arrives from the UART's shift
X register. For the old IBM PC with DOS this was sufficient.
X But for UNIX and with baud rates as high as 115200 this is
X just a bad joke.
X
X UNIX is not a real-time operating system. This means that
X its kernel isn't optimized for fast interrupt response.
X With properly designed hardware that buffers data until the
X OS has time to fetch it this is no problem. But since UNIX
X for PCs has to work with the standard hardware found in
X 286/386 systems, serial driver developers have to cope with
X the _N_S_1_6_4_5_0 UARTs which are in there simply to be compatible
X with IBM PCs, XTs and ATs under DOS.
X
X
X Rev. Release 2.11.0 Page 18
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X With this hardware it is impossible to make it work at high
X baud rates without a major redesign of the USL supplied UNIX
X kernel. But then it wouldn't be UNIX SYSV any more.
X
X Fortunately, there is a pin-to-pin replacement available
X from National Semiconductors: the _N_S_1_6_5_5_0_A.
X
X This device has separate 16 character FIFOs for the receiver
X and the transmitter. With these FIFOs the interrupt latency
X of the kernel can be quite high without losing characters.
X And because with most interrupts several characters are pro-
X cessed at once the CPU is loaded much less.
X
X So, as _F_A_S supports _N_S_1_6_5_5_0_A UARTs, all you have to do to
X fix the character loss problem is to either buy a serial
X card with _N_S_1_6_5_5_0_A chips on it or replace the UARTs on the
X card that you already have.
X
X If for some reason you can't get the _N_S_1_6_5_5_0_A chips you
X could use the _i_8_2_5_1_0 chips from Intel. Although they are
X much less efficient they are still better than the _N_S_1_6_4_5_0.
X
X There are, however, some conditions under which even the
X receiver FIFO in the _N_S_1_6_5_5_0_A UART can't prevent character
X loss:
X
X Other kernel drivers
X Some kernel drivers may disable interrupts for too
X long. One culprit is the disk cache flush routine.
X If you configure your kernel with too many cache
X buffers (_N_B_U_F parameter for USL derived UNIX) you may
X still lose characters (at least at 38400 bps and
X above).
X
X Another candidate is _V_P/_i_x, or rather the kernel func-
X tions to support _V_P/_i_x. This may also lead to lost
X characters at very high input speeds.
X
X Bus master controllers
X There are some bus master disk controllers (like the
X Adaptec 1540/1542 SCSI controller) on the market that
X slow down the CPU so much during data transfer that it
X isn't fast enough to process characters coming in at
X high baud rates.
X
X Therefore, if you can configure your disk controller,
X don't use values that will bring the CPU down to its
X knees. Otherwise, _F_A_S will lose incoming characters
X during disk I/O.
X
X If your operating system has a low interrupt latency you can
X define LOW_INT_LAT in the _M_a_k_e_f_i_l_e in order to set the
X receiver FIFO trigger level from 4 (default) to 8
X
X
X Rev. Release 2.11.0 Page 19
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X characters. This cuts the receiver interrupt frequency in
X half and therefore saves a lot of CPU time. That pays off
X especially at very high baud rates.
X
X If you set this flag you should do some rigid tests (receiv-
X ing characters at the highest baud rate while the system is
X heavily loaded with disk and network I/O) to make sure that
X there are really no lost characters due to interrupt
X latency. ISC UNIX 3.0 is known to have a low tty interrupt
X latency, therefore LOW_INT_LAT is defined in _M_a_k_e_f_i_l_e._I_S_C_3.
X On the other hand, ISC UNIX 2.x has a rather high interrupt
X latency and shouldn't have this flag set. For other UNIX
X flavors you have to find out yourself whether this flag is
X applicable.
X
X Device lockups
X There are certain conditions under which a device can lock
X up, that is, at least one process that uses this device
X waits for a tty I/O related event that apparently doesn't
X occure.
X
X The most common case is that there are still characters in
X the output buffer, but the output is disabled for some rea-
X son. Then the last process that closes the tty device hangs
X in the _c_l_o_s_e(2|S) function until the output buffer has
X drained.
X
X Tty output may be stopped by the software (XON/XOFF) or
X hardware (RRRRTTTTSSSS/CCCCTTTTSSSS, by default) flow control. In this case
X something seems to be wrong with the cabling or the con-
X nected device. Please check this first out before you blame
X _F_A_S. Sometimes it helps to switch the device off and on a
X few times to unblock the tty output.
X
X If this doesn't help the last resort would be to kill the
X process that hangs on the _F_A_S device, and if it still hangs,
X to open the respective device with the O_APPEND flag. This
X flushes the output buffers and therefore releases the hang-
X ing process. To do that, you simply type
X
X echo '\c' >> /dev/ttyF00
X
X if, for instance, the process is hanging on ttttttttyyyyFFFF00000000. Don't
X omit the backslash before the cccc!
X
X Another reason for a blocked output could be a lost
X transmitter interrupt. If this isn't caused by a configura-
X tion error this usually indicates a hardware problem in your
X computer which should be fixed as soon as possible. Other-
X wise, you can't run this system unattended because it is too
X unreliable. All you can do after a transmitter interrupt is
X lost is to reboot the machine in order to use the blocked
X _F_A_S device, again.
X
X
X Rev. Release 2.11.0 Page 20
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X If interrupts are lost on IRQ2 this might have to do with an
X EGA or VGA video card using this IRQ line for the vertical
X retrace interrupt. This interrupt isn't used at all these
X days, neither under DOS nor UNIX. It's simply there for
X compatibility.
X
X On some video cards (the more expensive ones) there is a
X jumper or dip switch to disable the vertical retrace inter-
X rupt. On the rest you have to cut the trace to the bus con-
X tact B4 with a sharp knife. This contact is on the solder
X side of the video card, the fourth bus contact counted from
X the side where the 9 or 15 pin D-SUB connector to the moni-
X tor is located. Cutting this trace has the same effect as
X pulling the IRQ2 jumper on other cards.
X
X Note that cutting the trace will void your video card's war-
X ranty.
X
X Now IRQ2 should be available for use with _F_A_S. Look at the
X _I_N_S_T_A_L_L_A_T_I_O_N file for details on how to configure _F_A_S for
X IRQ2. This is operating system dependent.
X
X And there is a rare case which has to do with the number of
X available CLIST buffers in the UNIX kernel. The UNIX output
X and input buffers are 256 bytes each (by default). If for
X some reason the output of a tty device is stopped but a pro-
X cess continues to send data one character at a time this
X uses up one CLIST buffer for every charcacter. If the
X number of CLIST buffers in the kernel is less than 222255556666 all
X CLIST buffers will be busy eventually.
X
X The dangerous thing here is that the pool of CLIST buffers
X is used by all tty devices of the system. Therefore, if one
X single tty device manages to eat up all available CLIST
X buffers all tty in- and output comes to a halt. If this
X happens you can't access your machine any more, not even
X from the operator console. Although the system is still
X alive internally.
X
X Unfortunately, many UNIX vendors have put a negligently low
X number-of-CLIST-buffers parameter into their kernel tune
X files. You should increase it to a value that makes it
X impossible that one device alone can occupy all CLIST
X buffers (it's the _N_C_L_I_S_T parameter under USL derived UNIX
X SVR[34].x). A value of 444400000000 should be sufficient.
X
X Background processes and _g_e_t_t_y problems
X Due to the design of the SysV kernel there might be problems
X with _g_e_t_t_y when the previous dialup user on the respective
X port was using background processes. Unfortunaley, _F_A_S
X can't do much about it.
X
X The reason for these problems is that when a device is held
X
X
X Rev. Release 2.11.0 Page 21
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X open by some process there can be no _g_e_t_t_y waiting for car-
X rier on this device. Notice that we are talking about the
X ssssaaaammmmeeee logical device for both the offending process and
X _g_e_t_t_y. This has nothing to do with the built-in modem line
X sharing for dialin and dialout.
X
X There are two problematic situations:
X
X 1. _g_e_t_t_y has already blocked in the _o_p_e_n(2|S) function
X and is waiting for the carrier. Another process now
X opens the device with O_NDELAY. Because the device is
X open after this there is no way for _g_e_t_t_y to remain in
X the carrier waiting state. Therefore _g_e_t_t_y is waked
X up and completes its _o_p_e_n(2|S) call as if the carrier
X were present. Of course, as the carrier isn't really
X there, subsequent _r_e_a_d(2|S) and _w_r_i_t_e(2|S) calls will
X return immediately with an EOF condition. _g_e_t_t_y just
X exits in this case.
X
X 2. A background process holds the device open when _g_e_t_t_y
X is respawned by _i_n_i_t. _g_e_t_t_y's _o_p_e_n(2|S) call suc-
X ceedes immediately because it can't block and wait for
X the carrier due to the device already being held open
X by the background process. Again, subsequent
X _r_e_a_d(2|S) and _w_r_i_t_e(2|S) calls return EOF (provided
X that the carrier is missing) and _g_e_t_t_y exits.
X
X In both cases _i_n_i_t will immediately respawn new _g_e_t_t_ys and
X eventually gives up with a ``respawning too rapidly'' mes-
X sage on the console. This disables dialins on this port for
X at least a couple of minutes.
X
X In this state you may notice that the DDDDTTTTRRRR line is low
X although it should be high as the port is held open by the
X background process. This is caused by the _F_A_S security
X feature that prevents modems from accepting calls when the
X port isn't ready for logins. This can save frequently cal-
X ling UUCP sites a lot of money. However, the security
X feature only makes the symptoms more visible, but it isn't
X the cause of the _g_e_t_t_y problems.
X
X While the first case above happens rarely (usually due to a
X configuration error) the second case is more common. The
X reason is that dialup users start background processes and
X then log off or drop the line. If the background process
X was started by a job control shell it runs in its own pro-
X cess group and therefore doesn't receive the SIGHUP signal
X sent by _F_A_S on carrier loss. It is the responsibility of
X the shell to notice either the SIGHUP or the EOF condition
X and to then kill its child (background) processes before
X exiting. Unfortunately, not all job control shells do this
X reliably.
X
X
X
X Rev. Release 2.11.0 Page 22
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X Another problem is that under some UNIX flavors the _c_s_h
X automatically disables SIGHUP for all background processes
X it starts. So these processes have no chance to terminate
X when the carrier drops.
X
X Whatever causes the background processes to survive the log-
X off or carrier drop, it causes massive problems with _g_e_t_t_y
X as described above. If you see these effects on your
X machine, and it can't be cured by using a better (in this
X respect) shell, your only option is to convince your dialup
X users to either not use any background processes or to
X redirect ssssttttddddiiiinnnn, ssssttttddddoooouuuutttt and ssssttttddddeeeerrrrrrrr to some files so that the
X processes don't hold the device open. If you or your users
X can't live without background processes on dialup lines you
X may want to install the _s_c_r_e_e_n virtual tty multiplexer which
X allows several independent screens to run programs even
X while you are logged off. _s_c_r_e_e_n or _i_s_c_r_e_e_n should be
X available on every GNU archive server.
X
X Crashes or video problems at boot time
X Several vendors of video cards with the S3 chip set (maybe
X with other chip sets as well) were stupid enough to use the
X I/O address 0000xxxx2222eeee8888 for their own purpose. This address, how-
X ever, has been used, at least inofficially, for the COM4
X port since the days the IBM AT came out.
X
X So what happens if you have such a video card in your com-
X puter together with an enabled COM4 port is that _F_A_S writes
X to the port at boot time (in order to detect it) and actu-
X ally writes to the video card as well, because of the over-
X layed I/O addresses. This confuses the video card so that,
X for instance, the screen gets dark, or it even manages to
X crash the system.
X
X The only thing you can do in this situation is to physically
X disable the COM4 port (usually by some DIP switch or jumper)
X and to tell _F_A_S (via its config files) not to use COM4.
X
X FILES
X /_d_e_v/_t_t_y_F??
X Dialout device with modem and hardware flow control (by
X default).
X
X /_d_e_v/_t_t_y_F_M??
X Dialin device with modem and hardware flow control (by
X default).
X
X SEE ALSO
X _t_e_r_m_i_o(7|M), _s_i_g_n_a_l(2|S), _o_p_e_n(2|S), _c_l_o_s_e(2|S), _r_e_a_d(2|S),
X _w_r_i_t_e(2|S), _f_c_n_t_l(2|S), _i_o_c_t_l(2|S), _g_e_t_t_y(1M|M), _c_u(1C|C),
X _u_u_c_i_c_o(1M|C)
X
X BUGS
X
X
X Rev. Release 2.11.0 Page 23
X
X
X
X
X
X
X FAS(7) UNIX System V FAS(7)
X
X
X
X _F_A_S is not yet ported to SVR4 STREAMS and therefore its
X functionality is limited under SVR4.
X
X DosMerge's virtual COM ports are unsupported.
X
X COPYRIGHT
X Copyright (C) 1990-1993 Uwe Doering
X See the file _C_O_P_Y_I_N_G (distributed with the source code) for
X distribution rights and restrictions associated with this
X software.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X Rev. Release 2.11.0 Page 24
X
X
X
SHAR_EOF
echo 'File fas.7.cat is complete' &&
true || echo 'restore of fas.7.cat failed'
rm -f _shar_wnt_.tmp
fi
# ============= fas.c ==============
if test -f 'fas.c' -a X"$1" != X"-c"; then
echo 'x - skipping fas.c (File already exists)'
rm -f _shar_wnt_.tmp
else
> _shar_wnt_.tmp
echo 'x - extracting fas.c (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'fas.c' &&
X/* FAS Final Async Solution driver for 286/386 versions of System V UNIX */
X
X/* FAS was developed by
XUwe Doering <fas@geminix.in-berlin.de>
XBillstedter Pfad 17 b
X13591 Berlin
XGermany
X*/
X
X#if !defined (M_I286)
X#ident "@(#)fas.c 2.11"
X#endif
X
X/* Note: This source code has been quite heavily optimized for speed.
X You may wonder that register variables aren't used everywhere.
X This is because there is an overhead in memory accesses
X when using register variables. As you may know data accesses
X usually need much more wait states on the memory bus than
X code accesses (because of page or cache misses). Therefore,
X saving some data accesses has higher priority than saving
X code accesses.
X
X You may also note some not very elegant constructions that
X may be intentional because they are faster. If you want to
X make style improvements you should check the assembler output
X whether this wouldn't slow things down.
X
X Decisions for speed optimization were based on assembler
X listings produced by the standard UNIX V [34].X/386 C compiler.
X
X IMPORTANT: On systems where FAS is to be compiled with the standard
X UNIX C compiler the assembler output file is optimized
X by an AWK script. That is, outb(), inb() and fas_mem_copy()
X calls are substituted with inline i/o mnemonics. As the
X intelligence of this script is limited it is necessary that
X the port address argument of outb() and inb() is a simple
X expression that allows the compiler to produce code that
X fetches the address with a single load operation. Look at
X the assembler output if you are in doubt about an expression.
X
X This is a kludge but it is the method that produces the
X fastest code with the standard UNIX C compiler.
X*/
X
X#include "fas.h"
X
X#if defined (__GNUC__) && !defined (NO_ASM)
X#if defined (XENIX)
X#define OUTB(port,val) \
X({\
X __asm__ volatile ("outb %%al,%%dx" : : "d" ((uint) (port)), "a" ((unchar) (val)));\
