David Laight wrote:
> On Thu, Jun 15, 2006 at 12:20:21PM -0700, Garrett D'Amore wrote:
>   
>> Any system with a reasonable UART FIFO should be able to do this.  Its
>> probably much more of an issue for i386's with busted UARTs,  where the
>> full overhead of the interrupt context switch has to be paid for *each*
>> character transferred.  If I had a SPARC classic, I would have been
>> happy to test this at higher rates.
>>     
>
> I have seen FIFO overruns on a 700MHz athlon at (IITC) 57600.
> I actually suspect the problem is due to interrupts being disabled (or
> an ISR running for a long time) rather than anything else.
> Unfortunately it didn't happen often enough for me to debug it, and
> now I have ADSL...
>   

If the serial port ISR (or even the soft interrupt code) can't run
quickly enough, you're going to have problems.  Nothing I do in com(4)
is likely to change that.

In theory, a lot of the handling for serial ports could be moved *out*
of a soft interrupt back into the mainline interrupt handler.  IIUC, the
main reason *not* to do it this way is that serial port interrupts tend
to be rather high priority, and calling up into other bits of the stack
with such a high interrupt level set is considered poor form.

There is a ring buffer in the middle that is used to transfer between
the hard and soft interrupts, but if the soft interrupt doesn't get
timely enough service, then even that will fill up.

Its possible that the size of it should be increased on some systems.

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".

    -- Garrett
> 	David
>
>   


-- 
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