Bell Tech 386 SysVr3
Greg Woods
woods at gpu.utcs.toronto.edu
Sat Aug 6 13:19:46 AEST 1988
In article <215 at milhow1.UUCP> how at .UUCP (Mike Howard) writes:
>In article <1988Jul30.141708.3175 at gpu.utcs.toronto.edu>, I write:
>>
>>> The Xenix serial driver cannot share interrupt vectors with more than
>>> one port.
>ok - but why is that a problem? Seems like the serial driver is busy
>enough that you _wouldn't_ want it to share a vector.
Unfortunately, it does share vectors. There are only 4 commonly
available interrupts for serial ports in the first place, and often 8
ports share one vector. Unless the board has hardware to "stack"
interrupts, characters will get lost. Even AT&T have had this problem
(see the SVR3.0 release notes for the 3B2).
>>> It will lose data at 1200 baud.
>Crap. I have a Compaq 286 (8 MHz) running SCO Xenix 2.2.1 with a Hostess
>8-port board as COM2. That board simultaneously drives:
To be specific, it was a 16 MHz Olivetti 386 running SCO Xenix V/286
2.2.1 with an AMI-LAMB 8-port as COM2. The eight'th port was looped
back into the first port. XON/XOFF was turned on, and a file was cat'ed
through at various baud rates. The resulting data loss showed why our
application was behaving so poorly (an RS-232 LAN). When we repeated
this test in various versions of the Olivetti 286, and in a 6 MHz
IBM-AT, the problem only escalated. The IBM even lost characters at 300
baud.
>Xenix is not always Xenix and performance depends on who ported it -
>especially the drivers.
I spent a lot of time on the phone with SCO, who wrote and ported the
version I was using.
>--
>Mike Howard
>uunet!milhow1!how
--
Greg Woods.
UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods
VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
More information about the Comp.unix.xenix
mailing list