From owner-freebsd-hackers Wed Nov 12 14:29:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA15765 for hackers-outgoing; Wed, 12 Nov 1997 14:29:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out5.ibm.net (out5.ibm.net [165.87.194.245]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA15759 for ; Wed, 12 Nov 1997 14:29:04 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-67.ca.us.ibm.net (slip129-37-53-67.ca.us.ibm.net [129.37.53.67]) by out5.ibm.net (8.8.5/8.6.9) with SMTP id WAA30020; Wed, 12 Nov 1997 22:28:28 GMT From: mouth@ibm.net (John Kelly) To: Terry Lambert Cc: bde@zeta.org.au, hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Date: Wed, 12 Nov 1997 23:29:39 GMT Message-ID: <346b36af.1755787@smtp-gw01.ny.us.ibm.net> References: <199711122154.OAA20137@usr05.primenet.com> In-Reply-To: <199711122154.OAA20137@usr05.primenet.com> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id OAA15761 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Nov 1997 21:54:42 +0000 (GMT), Terry Lambert wrote: >> Why can't we handle large bursts of input? > >Bruce can correct me, but I believe it's because the FASTINTR code >expects to run to completion, and that expectation means that it >can't take more than a small amount of time to process the interrupt. >Processing the additional caharacters puts it over the limit. Anybody know how high the limit is? >> Yes, but I don't see why the design of the 650 would make you want to >> handle it completely in hardware. >I don't think you can split interrupt types for this. I think the >reason the code is FASTINTR code is so that it can deal with the >characters and prevent an input overflow. If you can do that in >hardware, you should The 650 auto RTS function is "automatic" -- the chip knows when to raise RTS and suspend the input stream from the external device. In that sense, we would be "doing it in hardware." But that does not mean doing it "all" in hardware. My reason for wanting to use 650 auto RTS is to guarantee that interrupt latency will never cause the UART to be overrun and sio.c report silo overflows. I don't see that it matters whether it's ever invoked or not -- sio.c should be able to work pretty much the way it always has. > instead of doing it via FASTINTR to reduce the amount of code you > actually run at high spl. I don't want to split interrupt types. The serial ISR running at high privilege level can continue working the way it always has. The 650 auto RTS should work transparently to sio.c, with perhaps a few minor changes to accommodate the auto RTS/CTS and larger FIFO buffers. Someone has already tried to do this in sio.c, but it's not working right yet -- with auto RTS/CTS enabled, interrupt-level overflows occur. I'm trying to understand why so I can hack mine to make it work right. John