16550A in uport 3.0e ('386)

[T. William Wells]

In article <5113 at b-tech.ann-arbor.mi.us> zeeff at b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
: >: I have problems with the machine locking up when I install a 16550A
: >: on a uport 3.0e system and enable the fifo.
: >Yes.
:
: >I enable it by writing 0xC9 to I/O port 0x3FA when I boot.  I have
: >the standard driver.
:
: This is what I do and after some time (like overnight), I find that the
: process using the port is hung.  If I kill it and start another, the
: entire machine locks up.  It sounds like a driver problem to me, although
: I suppose it could be caused by some interaction with my serial card or
: the 16550A I have.

Here's what I've figured. First, certain of my problems are due to
flaky hardware. For example, I find that most mornings recently my
machine has crashed, as in totally locked up, no messages, nothing.
It is invariably midway through the expires that I do each morning.

This, plus crashes due to NMI's, is why I think there is a hardware
problem (my money is on something heat related or mechanical).  So,
after discounting these, the serial problems I have are these:

   1) Sometimes the serial port locks up. When I look at the serial
      chip, all seems well with it, except that data coming from the
      modem doesn't appear in the receive register. I tried sending
      data to the modem when it should have been in command mode
      (after a power cycle) and then reading the recieve register
      directly. Nothing. So, if I did that correctly, then the idea,
      expressed by Stuart Lynne, that my driver is losing interrupts,
      is not correct (or at least not relevant); however, the next
      time that this happens I'll go check out the state of the
      interrupt chip. (Oops! I'll have to go get a manual, I think
      mine have disappeared....)

   2) There is a bug in the Trailblazer firmware (confirmed by
      Telebit) that causes it to fail to deal properly with a dropped
      DTR around when it is hanging up the phone. This has, for me,
      the irritating effect of preventing it from reloading the modem
      parameters at the end of a call. Right now, I partly solve that
      problem by a using a wrapper about uucico to reopen the tty
      line and force a parameter reload.

   3) It does not appear to be possible to change the interface speed
      when the modem is off-hook.  This is a problem for me because,
      when I tried to use flow control instead of a variable interface
      speed it didn't work. So, I'm using varying interface speeds.
      This is a problem when, for whatever reason, the other system
      won't let go of the line. Then one has to figure out what speed
      the modem is operating at in order to get its attention or one
      must do something drastic like pulling the plug. (I have an
      unconfirmed suspicion that dropping DTR doesn't always force a
      hangup either, but I'll have to check that out later.)

   4) Sometimes the getty and whoever is calling will get into some
      kind of ping-pong loop. The worst I've seen there was when I
      started loosing keyboard interrupts; I unplugged the modem
      instantly, thus probably preventing a system crash.

      It occured to me, as I wrote the above, that here could be
      where your problem is: there used to be a UNIX bug wherein if
      all the clists were used up the system would crash. Suppose that
      your modem got into one of those loops and ran out of clists....

However, I should say that, by and large, my current setup works.
These problems, other than the first, tend to fix themselves; in
fact, only the last mentioned problem would seem to be a candidate
for a crash-causer.

: >BTW, have those poeple who had 16550A drivers in
: >beta released them yet?
:
: Good question.

I did get one answer to my question; he say's that he's been busy.
(Where did I hear that last? :-)

---
Bill
{ uunet!proxftl | novavax } !twwells!bill