[comp.unix.sysv386] Asynch session hangs .. any suggestions?

loc@yrloc.ipsa.reuter.COM (Leigh Clayton) (01/24/91)

 I run 386/ix 2.0.2, run a T2500 through a Computone 8-port card. (I
use the Computone just to increase my news-feed throughput .. which was
awful without it.) The PC is an Intel S302 (386-25) with 8M mainstore.

 There are quite a few extras on the box, but I don't think they're
relevant to the question I'm asking since the hangs only happen to one
person dialing in, and have never hit me though I dial in quite frequently.

 This person dials in at 2400 (he uses a GVC modem), and has tried a couple
VT100 terminal programs, including Procomm (which is what I use successfully).

 What happens to this person is that his line hangs, and nothing he can do
(including hanging up his phone and powering off his modem) can get the T2500
to hang up...it has to be manually reset to allow re-dialin (or out).

 I include here a message from the unlucky wight (he was using rn at the time)

    . Damn line is stuck again. Again, echoplexing seems to be working,
    . but no keys get a response from the system other than that.
    . I tried  ctrl x, ctrl z, ctrl c, ctrl l, break, h, ? , q, ctrl q,
    . and a few others. No go. Line is still busy after modem hangup (+++ath).

 By 'echoplexing' he means local echo, which suggests that the channel
to the Unix box is OK but the Unix shell is stuck somehow.

 He does use a rather noisy exchange, so line noise is a likely cause, but can
anyone suggest what is happening, what I can do to investigate the state of
the shell/driver (I don't have access to any Unix source, and I'm running
the standard driver (ie not FAS)), and what my user might do to reset the line
state?

 Thanks .../Leigh (And sorry for the length of this)

-----------------------------------------------------------
loc@tmsoft.UUCP                     uunet!mnetor!tmsoft!loc
loc@ipsa.reuter.COM                         (Leigh Clayton)

brando@uicsl.csl.uiuc.edu (Brandon Brown) (01/25/91)

loc@yrloc.ipsa.reuter.COM (Leigh Clayton) writes:


> This person dials in at 2400 (he uses a GVC modem), and has tried a couple
>VT100 terminal programs, including Procomm (which is what I use successfully).

> What happens to this person is that his line hangs, and nothing he can do
>(including hanging up his phone and powering off his modem) can get the T2500
>to hang up...it has to be manually reset to allow re-dialin (or out).

I had the same thing happening when I was using a Practical Peripherals 2400
Baud MNP5 modem. I kept pounding on it until I decided to try a Hayes
2400 Baud Smartmodem. It has worked like a top since. I have no explaination
as to why.

Have you verified that /etc/inittab is looking at the modem control for that
device? It is usually denoted by having a "d" in the device name; 
i.e. /dev/ttyd0...


+-----------------------------------------------------------------------------+
|  Brandon Brown                     | Internet: brando@uicsl.csl.uiuc.edu    |
|  Coordinated Science Laboratory    | UUCP:	 uiucuxc!addamax!brando!brown |
|  University of Illinois            | CompuServe: 73040,447                  |
|  Urbana, IL  61801                 | GEnie:    xmg23356, macbrando          |
+-----------------------------------------------------------------------------+

larry@nstar.rn.com (Larry Snyder) (01/26/91)

We also run a Computone (Intelliport) and have found
that the 3.14 firmware and 4.28 drivers are the only
ones which work correctly in our installation.

We lock the modems at 19.2, and use only hardware
flow control.   Their is a single gettydefs entry
(no-rotating) for each port -

here is part of our ic_control file:

ttyi03:
buffers:
receive%=50
communications:
baud=19200
stopbits=1
bits=8
parity=none
handshake=busyready
addcr=no

-- 
   Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis)
                        regional UUCP mapping coordinator 
  {larry@nstar.rn.com, ..!uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu}