Messages in this thread | | | Date | Tue, 22 Jul 1997 22:51:32 -0600 (MDT) | From | Rob Riggs <> | Subject | Re: 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. :)
| |