> Rob, what else do you have on your system? Although I haven't done the
> test in a while, the serial driver was originally written to be able to
> support 115kbaud on a 386/40. (Granted this was a kermit transfers, not
> PPP; but it was a looped back 115kbaud transfer where the transmitting
> and receiving ports were on the same CPU, doubling the work.)
This is a bad test. Why? Because if the recieving end stops working for
a tenth of a second, the transmitting end will too. No overruns/anything.
The transmit and receive paths of the tty code are quite separate. Just
because the receiving end stops working doesn't imply that the transmit
end will stop too.
It's true that if you have a problem with the IDE controller masking
serial interrupts, that will stop both transmit and receive interrupts,
but the flip buffer overflow indicates that we're having a problem
gettin the bottom-half driver running quickly enough, and the transmit
path isn't dependent on any BH drivers.
I too have a 486/66, this time the serial ports are on a specialix
card, not the standard serial ports. The flip buffers overflow when I
get the machine paging heavily. It'll be doing a few hundred IDE
interrupts per second around that time.....
Well, the cop-out solution would be to have a CONFIG option which
allocates a separate 4k page for the flip buffer, so that instead of a
512 byte flip buffer, you have a 2048 byte flip buffer. That'll solve
the problem on slower machines that for some reason can't handle things
quickly enough. (Obviously if we do this we would need to only allocate
the memory for those tty's that actually use the flip buffer. For
example the pty's don't use the flip buffer, and my latest Rocketport
driver doesn't use flip buffers anymore.)
I can't help thinking that we're missing something big though; if the
flip buffer processing is getting delayed this long, there's something
wrong going on.
- Ted