Maybe this major changes of 2.0.x should go in 2.1.x ...
On 23-Jul-97 Rob Riggs wrote:
>
>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. :)
- ---
Manuel J. Galan
manolow@step.es
Sent on 23-Jul-97 15:04:17
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: Requires PGP version 2.6 or later.
iQB1AgUBM9YPZtLJkgqGw1hxAQEEWwL9GwSDE0PZY+VQ0azc4q/hZNso3KlMxF/A
xcCDYtF7doZ3cjUImusFxfOpzVnyfBYtQEMWPWmPO2cYOGvICP43qAY4I4Oo3Xp7
iZPTmYEZT2J9VIU851IQOk+7FdbCn4R2
=vhb/
-----END PGP SIGNATURE-----