Messages in this thread | | | Date | Tue, 22 Jul 1997 17:14:10 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: 2.0.30 serial.c, ppp.c and pppd-2.2 questions |
| |
Date: Tue, 22 Jul 1997 21:59:19 +0200 (MET DST) From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
> 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
| |