From owner-freebsd-hardware Wed May 21 00:16:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA24161 for hardware-outgoing; Wed, 21 May 1997 00:16:53 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA24155 for ; Wed, 21 May 1997 00:16:48 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.5/8.8.5) id AAA27493; Wed, 21 May 1997 00:17:48 -0700 (PDT) Message-ID: <19970521001748.32607@hydrogen.nike.efn.org> Date: Wed, 21 May 1997 00:17:48 -0700 From: John-Mark Gurney To: Bruce Evans Cc: brett@lariat.org, HARDWARE@FreeBSD.ORG, rberndt@nething.com, WELCHDW@wofford.edu Subject: Re: isa bus and boca multiport boards References: <199705210516.PAA05401@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199705210516.PAA05401@godzilla.zeta.org.au>; from Bruce Evans on Wed, May 21, 1997 at 03:16:17PM +1000 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce Evans scribbled this message on May 21: > >>Since the entire set of ports must be scanned whenever an interrupt occurs, > >>maybe there is too much delay in getting to the upper ports. Something gets > >>locked up if they overflow. I left several messages, but no one could > >>figure it out. > > Probably not. Scanning all (inactive) ports takes about 1/4 as long as > handing one fully active 16550 port. Scanning 16 fully active ports > at 115200 bops takes too long for the default (unconfigurable :-() > fifo trigger level. However, having 16 fully active ports is rare. so should I commit my changes that allow the sio to set 16550's to a trigger level of 8? and possibly make it more generic than it already is and allow people to define the resulting fifo level of the uart? > Nope. There are only some minor C inefficiencies in the important parts > of the driver. The code is within 50% of best possible generic i386 > assembler code by static instruction counts, but this is unimportant hmm... now just to get a compiler like Watcomm that has optimization that works and isn't broken... a friend has this and he literally looked at code outputed by it, and couldin't inprove the asm output at ALL... of course you'd need to convince them to add support for FreeBSD's a.out format as right now it's a DOS/Win/OS2 based compiler... :( -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD