[comp.unix.i386] IPC-802 port board and Telebit Trailblazer modem

lenny@alps.UUCP (Lenny Tropiano) (09/12/89)

This has happened several times, and it's becoming quite annoying.  Right
now we are running a 6386E WGS with 4MB of memory and an IPC-802 port board
with Version 3.0 of the drivers.   Six of the ports are allocated to direct
terminals, or connections to our 3B2 and UNIX pc (using uugetty).  Two
of the ports, ttyh07 and ttyh08 are allocated to dialout modems.  The
Trailblazer is on ttyh07 and the AT&T 4024 modem is on ttyh08.  

It seems sometimes while cu'd to a particular site the modem will hang
(this occurs sometimes while operating normally, or while disconnecting).
Then the cu process will hang too.  I attempt to do a "~." and it will
just sit there and not disconnect from the modem.  It seems like the
modem is in some sort of I/O wait state, and will not relinquish the
process.   I then toggle to an alternate VT (alt-sysreq-F1) and then
attempt to kill the cu processes.   Sometimes the second (child to cu)
process is still there while the first one is in zombie-land (<defunct>).
The child is then attached to init (pid=1).  No signals, even -9 will
kill the process.   Logging out on the terminal that acquired the modem
doesn't even kill the process.  Only resource is to shutdown.

Most of the time I will get the following messages on the console:

	uugetty: cannot open "ttyh0#": errno: 6
	...
	uugetty: cannot open "ttys0#": errno: 6

     UID   PID  PPID  C    STIME TTY      TIME COMMAND
    root     0     0  0 07:41:11 ?        0:10 sched
   ...
   lenny   533   314  0                   0:00 <defunct>
   lenny   534     1  0 09:53:50 console  0:20 cu burket 

Sometimes the events that lead up to it is that all the terminals on
the machine just come to a screaching halt... slow down, whatever.  Then
I get the uugetty messages.

The cable configurations on both modems are as follows: (we are using
RJ-45 8 conductor cable with RJ-45 to DB-25 connectors on both ends)

     .. 1 ---------------- 1 ..
     .  2 ---------------- 2  .
     .  3 ---------------- 3  .
     .  4 ---------------- 4  .
     .  5 ---------------- 5  .
     .  6 ---------------- 6  .
     .. 7                  7 ..
        8 ---------------- 8
       20 ---------------- 20

Any suggestions would be appreciated!

-Lenny
-- 
Lenny Tropiano,  Project Manager / Sr. Software Engineer
American LP Systems, Inc.      E-MAIL   : ...{icus,rutgers,sbcs}!alps!lenny
305-1 Knickerbocker Avenue     AT&T MAIL: ...attmail!alps!lenny
Bohemia, New York    11716     PHONE    : 1-516-589-7930

johnk@opel.uu.net (John Kennedy) (09/13/89)

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

sean@ms.uky.edu (Sean Casey) (09/15/89)

lenny@alps.UUCP (Lenny Tropiano) writes:

[problems with a trailblazer on an IPC-802]

You might want to beg a software update from AT&T. We just got shipped
two new boards that came with software rev 3.09. In the docs it lists a
*lot* of gross problems they fixed. An embarrassing number of problems.

Sean
-- 
***  Sean Casey          sean@ms.uky.edu, sean@ukma.bitnet, ukma!sean
***  Copyright 1989 by Sean Casey. Only non-profit redistribution permitted.
***  ``Why can't anything be as simple as following the instructions???'' -me

lenny@icus.islp.ny.us (Lenny Tropiano) (09/15/89)

In article <12683@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes:
|>lenny@alps.UUCP (Lenny Tropiano) writes:
|>
|>[problems with a trailblazer on an IPC-802]
|>
|>You might want to beg a software update from AT&T. We just got shipped
|>two new boards that came with software rev 3.09. In the docs it lists a
|>*lot* of gross problems they fixed. An embarrassing number of problems.
|>

For some reason I tend to think the software release revision 3.09 is
for the MSDOS Drivers.   I believe the most up-to-date release to the
UNIX Drivers is 3.0 (which I was running when talking about those problems)...

-Lenny
-- 
Lenny Tropiano             ICUS Software Systems         [w] +1 (516) 589-7930
lenny@icus.islp.ny.us      Telex; 154232428 ICUS         [h] +1 (516) 968-8576
{ames,pacbell,decuac,hombre,talcott,sbcs}!icus!lenny     attmail!icus!lenny
        ICUS Software Systems -- PO Box 1; Islip Terrace, NY  11752

fmcgee@cuuxb.ATT.COM (~XT6561110~Frank McGee~C23~L25~6326~) (09/20/89)

In article <12683@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes:
>lenny@alps.UUCP (Lenny Tropiano) writes:
>
>[problems with a trailblazer on an IPC-802]
>
>You might want to beg a software update from AT&T. We just got shipped
>two new boards that came with software rev 3.09. In the docs it lists a
>*lot* of gross problems they fixed. An embarrassing number of problems.

I'd agree.  The 3.0 drivers fix many, many bugs, and to my knowledge
none of the 3.0 users have come up with problems that relate to the
driver (usually it's cabling issues).  If you want the new driver,
it's FREE from the hotline at 1-800-922-0354.

As for MSDOS usage, I believe it states in the new manuals that come
with the driver that neither the IPC 802 or IPC 900 is recommended for
MSDOS use.  Not recommended, and if you really need it I'd recommend
you go to a different vendor if you're going to use it under MSDOS.
The board works great under Unix though (if you have the 3.0 driver).

-- 
Frank McGee, AT&T
Tier 3 Indirect Channel Sales Support
attmail!fmcgee