From owner-freebsd-current Wed Mar 4 20:49:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA27908 for freebsd-current-outgoing; Wed, 4 Mar 1998 20:49:13 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero-fxp0.Simon-Shapiro.ORG [206.190.148.34]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA27901 for ; Wed, 4 Mar 1998 20:49:09 -0800 (PST) (envelope-from shimon@sendero-fxp0.simon-shapiro.org) Received: (qmail 19706 invoked by uid 1000); 5 Mar 1998 04:55:51 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-021598 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199803050348.TAA23945@dingo.cdrom.com> Date: Wed, 04 Mar 1998 20:55:51 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: silo overflows (Was Re: 3.0-RELEASE?) Cc: Matthew Thyer , current@FreeBSD.ORG, Evan Champion Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 05-Mar-98 Mike Smith wrote: ... > 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. I will not comment on this at all... ... >> 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. Brain-Dead. Then all bets are off. In the current software + hardware structure, interrupts will be lost. > Lowering DSR won't help much, because it's an input. Picky, picky, I mean DTR, and you know it :-) > 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. Modems must and do comply with RTS/CTS. All the ISPs out there that have a flow control with Sportster, raise your hand... A modem that does not is broken. Many modems bastardized this support to acomodate operating systemsd that did too. But there is normally a mode where it will work. ... > The ZSIO is completely unrelated to the 8250. It has more in common > with the 2681/68681 family and the 8530 SCC. sorry. Last I touched one of these has been longerthan I can hold information. > Unfortunately, you cannot expect a peripheral to respond in this > fashion. Automatic handshaking can also significantly reduce throughput > unless very carefully managed. Again, you are convincing me why something that works cannot (or is hard to make) work. I cannot agree to that, as I see modems, telex machines from yore, computers, PCs, all working fine without dropping a single byte due to internal overflow. Since the system is useful to me, in this state, I have no further complaints. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message