I'm writing to ask if anyone knows about the technical behavior of the AST
4-port serial card and, if so, if they'd be willing to answer a few
questions I have concerning the card.  First, let me say that this
explanation will be somewhat long, so please bear with me.
	I have an AST 4-port card which I am running on my NetBSD-09a 
system.  Since the system I'm running predates the actual official release
of the ast driver, I decided to back-port it to my system.  After about a
week of not getting it to work, I decided to try bringing my system to
current.  When I did, I still couldn't get it to work.  There seemed to be
some weird interrupt thing going on, but since vmstat -i didn't work on the
current system, I couldn't really see what it was.  Finally, I went back
to the old system and tweaked my back-port into enough of a functional
state so that I could use the system with its serial ports.  I noticed that
if I used the traditional ports as well as the ports on the ast card, the
machine would lock up very quickly, and, just before doing so, the serial
ports would freeze.  If I used only the ports on the card, they would work,
but vmstat -i would show that interrupts were getting generated for com0
and com1 as well as for the ast card.  Since there was no usage on the
regular ports, I noticed that, if I used port 0 on the ast card, the
interrupt count for com0 matched the interrupt count for the ast card.  If
I used the second port on the ast card, the interrupt count for com1 would
match the interrupt count for the ast card.  All this when the ast card is
configured to run in enhanced mode.  So, my first question is:
	1.  If the ast card is configured to run in enhanced mode, are its first
two uarts supposed to generate irq requests on irq 4 and 3 respectively in 
addition to the multiplexed interrupt?
If they are, is there some setting of the switches, or some magic register
I need to poke to get them to stop?  (See the end of this message for a
transcript of sample vmstat figures.)

	Then I noticed that the ast card is generating a huge number of interrupts
per second.  This might be due to the fact that I'm not doing some reset
properly in the interrupt handler, but that's my second question.  
	2.  Is there some specific register I need to reset, when servicing an
ast interrupt, which resets the master interrupt state so that it will
actually stop interrupting until the next port on the board really needs
servicing?  I've looked at the ast driver for later versions of NetBSD, but
don't quite see where it resets the interrupt.  From what I can tell, it
just calls the normal service handler for the com ports as they're needed.
Since I'm still using the old com code (ported to a separate ast driver,
rather than the com code for the current version of NetBSD), is there some
impllicit resetthat takes place in the newer driver that did not get done
in the old one?  

	It might be that these two questions are related, but I'm not sure.  
If anyone can provide any helpful insights to these questions, I would be
most appreciative.  

Thanks very much for any help in advance.

===technical information===

sources: February 2, 1994.
system: 486dx/2 66 with 16MB RAM, 32MB swap.
Technical info:
Here is the specific information on vmstat.  The machine has been up for
about 15 hours and here is how the interrupts shake out.  

%uptime
 4:52pm  up 16:38,  1 user,  load average: 0.02, 0.03, 0.00
%vmstat -i
interrupt         count     rate
stray irq           399        0
clk irq0        5990291      100
fdc0 irq6             1        0
bt0 irq11         35401        0
npx0 irq13          399        0
com0 irq4     222848363     3720
com1 irq3        864966       14
ast0 irq5     116723346     1948
is0 irq9              1        0
Total         346463167     5783

The stray interrupt is the result of me taking out the lpt driver to see if
I could isolate the problem with my own ast driver.  I don't know if the
interrupt is actually being generated by the parallel port itself, but
since the number of interrupts are so few, I could believe that they are
actually coming from the parallel card.

P.S.  If anyone needs more technical information, please let me know.  I'd
love to dialogue with someone on this.
-thanks
-Brian

------------------------------------------------------------------------------