Date: Wed, 04 Mar 1998 19:48:11 -0800 From: Mike Smith <mike@smith.net.au> To: shimon@simon-shapiro.org Cc: Mike Smith <mike@smith.net.au>, Matthew Thyer <Matthew.Thyer@dsto.defence.gov.au>, current@FreeBSD.ORG, Evan Champion <evanc@synapse.net> Subject: Re: silo overflows (Was Re: 3.0-RELEASE?) Message-ID: <199803050348.TAA23945@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 04 Mar 1998 19:40:24 PST." <XFMail.980304194024.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > However the driver has no say in the matter when _someone_else_ > > disables interrupts for a long period of time, or when the hardware > > fails to deliver them in the first place. > > Unless I misunderstand something, the driver should get interrupts > delivered, unless another part of the kernel is in spltty(), or another spl > which masks spltty. There should not be all that many of those, and they > should be considered carefully. I *did* suggest that you read the code. I meant it. The sio(4) driver (and a few others) use what are called "fast interrupt handlers". These are spl-immune, and can only be blocked with disable_intr(). Delivery of these interrupts may also be delayed at the hardware level. > Now, if something in the kernel disables interrupts althogether for any > amount of time, he should get the pointy hat everyone like to talk about so > much, as this will make FreeBSD into a glorified Linux. I did ask if someone would perhaps investigate this. > > If you have a solution to this really quite challenging problem, I'm > > sure we'd all be delighted to hear about it. Until then, please > > believe me that there is nothing wrong with the driver, per se., which > > "causes" these overflows. > > Again, don't decapitate me on this one, but does not the 16550 have a mode > by which it will lower DSR and or CTS when the FIFO reaches a certain point > of saturation? No, it doesn't, although some of the extended versions do. Lowering DSR won't help much, because it's an input. Automatic RTS/CTS flow control is only useful when you are talking to another UART that implements a comparable scheme. Many serial devices will only respond to changes in flow control signals at the start of an output block, ie. there is no guaranteed response to a change in RTS state. > This will stop the modem from transmitting characters > within one character time period. Any modem which will not do that is very > broken. This i have done suvvessfully on a Z-80, using a Z80-SIO USART ( a > cusin of the 8250 if i remember right). The ZSIO is completely unrelated to the 8250. It has more in common with the 2681/68681 family and the 8530 SCC. Unfortunately, you cannot expect a peripheral to respond in this fashion. Automatic handshaking can also significantly reduce throughput unless very carefully managed. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803050348.TAA23945>