On Tue, Aug 19, 2003 at 12:14:46PM -0700, Michael South wrote:
> > Now, the same interrupt pin should cause the comintr(...) isr
> > to be called at priority IPL_SERIAL and the pciio_intr(...)
> > isr to be called at priority IPL_TTY. The comintr(...) function
> > is the generic comport interrupt handler [...] This interrupt
> > handler however, will not clear the pci-interrupt pin - that is
> > controlled by the PCIIO card & driver. [...] The PCIIO driver
> > will clear the interrupt on the PCIIO device once nothing else
> > needs to be dealt with on the PCIIO.
> 
> The card's interrupt  pin won't get cleared while IPL_TTY is blocked.
> Doesn't this mean that the next com interrupt won't trigger until
> then?


Yes, this may be the problem. I don't think new interrupts on the pin
will be noticed until all current interrupts have been serviced.
You'll probably need to poll the IPL_SERIAL interrupt handler from others
interrupt handlers for this PCI adapter.

If you really have, on the same board/interrupt line, different devices
with different requirements in interrupt servicing, you'd probably better
go the soft interrupt route for the lower priority devices (unless their
interrupt handler is really fast).

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--