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-7930johnk@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???'' -melenny@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