lkml.org 
[lkml]   [1997]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.0.30 serial.c, ppp.c and pppd-2.2 questions

On 23-Jul-97 Theodore Y. Ts'o wrote:
>The patch you submitted doesn't work, because it uses a static variable,
>flip_overflow. If you have multiple serial ports active, they will all
>try to reference same flip_overflow variable while the interrupt routine
>is executing, with really bad results.

You mentioned the one bug in that crappy patch file that I missed.
Easy enough to fix. It also had a bad variable name, it would
overflow the flip buffer if the last possible character also
indicated overflow, and the logic for flagging the overflow
error is wrong, but other than that... :)

>(Insert standard claim about why I think threads are a bad idea for most
>application programs; there are plenty of kernel programmers have a hard
>time writing thread-safe kernel code --- and we expect *application*
>programmers to be able to get this stuff right? It's like handing a
>loaded .45 to a chimpanzee and hoping he won't shoot himself or others
>while he's playing with it. :-)

:) point well taken.

>BTW, the basic idea in your patch was a good one; you just have to put
>the flip_overflow flag in the info structure.

And fix a few other things... I can get a corrected patch to you
if you are still interested.

I have been running a modified serial.c under 2.0.30 for some
time now. It includes some support code backported from 2.1.43,
as well as some major modifications.

My current code supports the following features:

16650A, 16654, 16750 UARTs
Correct handling of flip buffer overflows
*Automatic flow control (for above mentioned UARTs)
*Flip buffer flow control
*Configurable tx/rx trigger levels
*diagnostics
+receive_chars() optimized for the normal (no errors) case

* = settable via setserial(8)

+ = The current code checks for every possible error,
for every character received (unless they are ignored),
before it decides it is OK. The new code checks if the
status is OK first and skips the rest of the checks if
it is. It should be a little faster when servicing the
interrupt.

I will be putting it up on my hompage for constructive critisism
shortly. With the current patch I am getting 13.5KB/s FTP transfer
rates over (non-compressed) 128Kbps ISDN. This is far better than
I was able to achieve before.

The biggest help for me seems to have been the use of the larger
FIFO on the 16650A (1/2 - 1/3 the number of interrupts), followed
by the flip buffer flow control. Automatic flow control helped
with the FIFO overruns, but I was getting far more flip buffer
overruns than FIFO overruns. With the FIFO trigger set properly
FIFO overruns almost never occur.

I hope you will have a chance to look it over.

-Rob

P.S. I originally started working on this because A) the
number of dropped packets from my PPP connection made
128K ISDN actually slower than 64K ISDN, and B) the
PPP connection would spontaniously freeze on me when
running at 128K MLPPP. The errors from both were "ppp:
frame with bad fcs", though right before the PPP link
froze, I would get about 20 of those messages in a row.
I thought the problems were related and went looking
into the kernel for a possible cause of the dead PPP
connection and dropped packets, and found the problem
with the flip buffer overflowing.

The work on the above code helped eliminate the
flip buffer problems and got the throughput on the
128K ISDN up to where it should be, but I would still
get a flurry of "ppp: frame with bad fcs" messages
and the PPP connection would go dead.

My original belief that they were related was unfounded.

The ISDN TA is bad. :)

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.077 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site