Subject: Re: com rumblings...
To: John F. Woods <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 06/15/2006 13:26:37
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
Phone: 951 325-2134 Fax: 951 325-2191