From owner-freebsd-current Wed Mar 4 19:53:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA15918 for freebsd-current-outgoing; Wed, 4 Mar 1998 19:53:09 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA15874 for ; Wed, 4 Mar 1998 19:53:04 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id TAA23945; Wed, 4 Mar 1998 19:48:12 -0800 (PST) Message-Id: <199803050348.TAA23945@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: shimon@simon-shapiro.org cc: Mike Smith , Matthew Thyer , current@FreeBSD.ORG, Evan Champion Subject: Re: silo overflows (Was Re: 3.0-RELEASE?) In-reply-to: Your message of "Wed, 04 Mar 1998 19:40:24 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Mar 1998 19:48:11 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > 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