Xref: utzoo comp.sys.att:7563 comp.unix.i386:436 comp.dcom.modems:4464
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!opel!johnk
From: johnk@opel.uu.net (John Kennedy)
Newsgroups: comp.sys.att,comp.unix.i386,comp.dcom.modems
Subject: Re: IPC-802 port board and Telebit Trailblazer modem
Keywords: TB, 19200, uugetty, IPC, 6386E WGS
Message-ID: <275@opel.uu.net>
Date: 13 Sep 89 08:17:45 GMT
References: <103@alps.UUCP>
Reply-To: johnk@opel.UUCP (John Kennedy)
Organization: Second Source, Inc., Annapolis, MD
Lines: 29

We had problems with the IPC-802, where either the first four or
last four ports on the box would hang.  It seems that there are a
pair of z-80's in the 802 that each control four, and some level
of redundancy is provided if one of the processors goes out to lunch.

However, I've seen problems such as you describe with cu, even on 
"dumb" ports.  It seems that I've gotten out of the hung single process
by killing the shell that the user had cu'd from, but that doesn't seem
to be helping you.

I assumed it was a bug in the close logic, where something in the
kernel is insisting on some sort of response from the device, which
isn't going to happen.

BTW, we got rid of the IPC 802 and replaced it with an IPC 900.  Different
packaging (all on one internal card with modular connectors), but still
a pair of z-80's and probably the same firmware.  The drivers you use
remain the same.

Can't say that we've seen your particular problem on either IPC.

John



-- 
John Kennedy                     johnk@opel.UUCP
Second Source, Inc.
Annapolis, MD