John F. Woods wrote:
>> I need to verify what we are seeing though -- is it a hardware FIFO
>> overrun, or the ring buffer filling up?  com(4) shows hardware fifo
>> overflows as "silo overflows" and ring buffer fills as "ibuf floods".
>>     
>
> I see
>
> 	com1: 1 silo overflow, 0 ibuf floods
>
> from time to time on a full-time modem link with a 350MHz P4.  The serial
> port is a 16550A (or emulation thereof) with a putatively "working fifo",
> according to dmesg.
>
> This is probably something simply sitting on the interrupt mask for way
> too long, and the com(4) driver is thus not at fault.  But it would be nice
> to figure out what is blocking interrupts for tens of milliseconds or however
> long this works out to be...
>   

I concur with your assessment.  Some thoughts:

    * what else is on the same IRQ line?  anything?
    * check i386 interrupt handling for proper prioritized interrupt
support (I'm i386 ignorant as far as NetBSD is concerned)
    * is some code somewhere doing an expensive splhigh() or somesuch? 
Perhaps spin-waiting on something?

Frankly, I suspect the last, but I'm neither equipped or prepared to
investigate further at the moment.  I strongly suspect that my com(4)
changes will not impact this one way or the other.

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191