[Gllug] re: serial buffer overrun

[t.clarke]

Peter Childs wrote:

>> A search on the web reveals a setserial package at sourceforge whic has amongst
>> other features a 'latency' feature (which is presumably controlled by the rx
>> trigger level).   You could try downloading, compiling, and using this.
>> Setting a 'low latency' may then cure the problem.
>>
>> However, the question still remains as to why this is happening anyway:
>> since uart overruns are simply due to the cpu not being able to clear the
>> receive buffer on the uart fast enough, the possibilities would seem to be:
>> a) running the serial line too fast
>
>4800bps too fast?
>

If your serial port is losing characters at only 4800 bps, the problem may be solved by
reducing the trigger level (at that speed), but I would guess you have another
underlying problem to solve.


>> b) cpu too slow
>
>Modern Processor too slow? Serial Lines have been in use for the last 30
>years (think again)

I imagined you might have been running an old CPU and using the serial
port at 115,200bps - in which case the CPU might not keep up !

>
>> c) cpu overloaded with other non-interruptible load
>
>        As many pages on the internet "Caused by a multi-process"
>environment.

Not sure what you mean by this - I was referring to the possibility
of the CPU, for whatever reason, spending a lot of time in a mode
where the serial port interrupt is masked out. Highly unlikely I
guess, but maybe a possibility !

>
>> d) crap uart with too small a buffer (any decent mobo should be using a 16550
>>    or compatible uart)
>
>        You mean 16550A. The 16550 is crap its only got a 1 byte buffer.

Yes, sorry, I did.   I assume from your reply that you are using a 16550A.

>
>> e) problems with the serial driver code ??
>
>        Linux Kernel?

But which kernel ?
Maybe you are using a new kernel with a new driver with a bug in it
- I am merely pointing out *possibilities*

>
>> f) shared interrupt not being handled efficiently ??
>>
>> I have a vague feeling that the driver reports on receiver buffer overruns
>> - available by interrogating the appropriate /proc filesystem entry.
>>
>> A post containing details of your hardware/o-s config might be helpful to
>> others to assist.
>
>
>        I'll have a look at sourceforge.

Be interested to hear on the list your final solution.

Tim


-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug