Computone + modem = ?

[Bill Blue]

In article <234 at usource.UUCP> frankb at usource.UUCP (Frank Bicknell) writes:
>Assuming a disabled port, when the machine is booted, DTR
>remains off (so far so good).  Now, I enable the port, and DTR
>comes on (great so far).  However, when I disable the port or
>kill getty (same thing, sorta), DTR remains on!  I check 'ps'
>and the getty is indeed dead; no other processes have that tty
>ensnared.
>
>Well, I called Computone, and they said, "Oh, you need the new
>firmware and drivers," which they promptly sent free of charge
>(thank you, Computone).  However, the thing behaves in exactly
>the same way.  Now their tech support says, "gee everyone else's
>works right...  let's see if we can reproduce it here."  Well,
>that's been about a week and nothing so far.  Meantime the modem
>sits there.

I haven't seen this exact problem with dtr not going low on
a disable, but there are still a lot of bugs in the Computone
drivers.  I have been going round and round with Computone for
months now trying to get them all fixed.  To their credit, they
have gotten some of the uglier ones fixed:

	1. upward dcd transitions would be ignored.  Not too
useful on a modem control line.  Fixed.

	2. uucp simply couldn't talk if the device used was
a major computone port (m0 as opposed to i0).  This was really
difficult to track down, and once I did it took forever getting
them to believe it.  The problem was that they weren't initializing
the ioctl structure to a known state (all zero's, basically).  
So when it was passed to an application which &= and |= to set
states, it would fail.  If all parms were set absolute, it would
work.  Fixed.  Grudgingly.

	3. flushing problems.  Partly fixed.

The above problems are fixed in the drivers I'm using, which are '4.37
beta'.

However, there are still other problems with the drivers, which so
far, I have not gotten them to fix.  "Gee, no one ELSE is having that
problem."  They are:

	1. A Computone port which is used for dial in and dial out
will not restart the dial in getty once it has been used for dial
out.  uucp terminates and the port just sits there with dtr low.
Real useful.  Of course, things work perfectly with a com port.

	2. A user connected to the system via a Computone port at a
slower speed ( <4800bps ) will get about a full screen page of text
after using the interrupt key.  This should (and does on a comm port)
immediately abort output and flush buffers, but doesn't on a Computone
port.

	3. When a Computone port is used on a dial in line, that may
experience much traffic, noisy lines, modems that won't 'sync' up,
etc., it is likely that such a port will eventually die (can't kill
it, can't disable it) or end up with several getty's sitting on it,
any one of which can't be killed unless (sometimes) you start with the
newest one first and work your way backwards.  In either scenario,
issuing an '/etc/ic_init -please' which reinits the ports at the
Computone driver level, will then allow you to kill the processes that
wouldn't kill before.  This one is particularly aggravating, because
the ic_init will change some stty settings on ports that are working
correctly, upsetting what other users may have going on.

I'm hoping there are fixes to these in progress, but I'm not holding
my breath.

I'd like to hear from anyone else who might be experiencing these
problems or variations of them.

--Bill