Xref: utzoo comp.sys.att:5134 unix-pc.general:2011
Path: utzoo!utgpu!watmath!clyde!att!mtunb!jcm
From: jcm@mtunb.ATT.COM (was-John McMillan)
Newsgroups: comp.sys.att,unix-pc.general
Subject: Re: Answers to UNIX PC Commonly Asked Questions
Keywords: 3b1 question answer
Message-ID: <1357@mtunb.ATT.COM>
Date: 9 Jan 89 13:40:21 GMT
References: <2938@datapg.MN.ORG> <772@cgh.UUCP>
Reply-To: jcm@mtunb.UUCP (was-John McMillan)
Organization: AT&T ISL Middletown NJ USA
Lines: 22

In article <772@cgh.UUCP> paul@cgh.UUCP (Paul Homchick) writes:
>In article <2938@datapg.MN.ORG> sewilco@DataPg.MN.ORG (Scot E Wilcoxon) writes:
>>11. Some AT&T serial boards do not work right.  How are they identified?
>>
>>The EIA boards (or EIA/RAM) in question are anything RELEASE F or higher.
>
>Does anyone know what symptoms are displayed by these boards that "do not work
>right?"  ...

The problem was originally reported as:
	The system locks up -- for many seconds -- or crashes upon receipt
	of a BREAK sent from a remote user.
Analysis showed this was due to the DUART repeatedly interrupting and
stacking a huge number of interrupts.
	There is a growing suspicion that UUCP transfers are putting the
	chip into the same state.  Any UUCICO cognoscente care to comment
	on its use of BREAK?
The problem seems to lie in combo-board reworking -- by one report,
unsolicited -- as of Rev-F that belatedly uncovered a design-(mask?-)error
in one vendor's chips.  Makes ya really paranoid about "progress".

jc mcmillan	-- att!mtunb!jcm	-- muttering for himself, only