From owner-freebsd-hackers Fri Dec 13 01:29:03 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA04844 for hackers-outgoing; Fri, 13 Dec 1996 01:29:03 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA04838 for ; Fri, 13 Dec 1996 01:28:59 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id UAA27331; Fri, 13 Dec 1996 20:22:40 +1100 Date: Fri, 13 Dec 1996 20:22:40 +1100 From: Bruce Evans Message-Id: <199612130922.UAA27331@godzilla.zeta.org.au> To: hackers@freebsd.org, suttonj@interconnect.com.au Subject: Re: My Banksia Internal Modem - sio driver Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >(after numerous reboots) and sometimes not. So I did some searching of the >mail archives and realised that I should use the 0x80 flag to see what was >happening (should have read the sio man page...). I suddenly found that it >was failing consistently on the 6th probe: > >/kernel: sio1: probe test 6 failed > >Thinking I had nothing to loose I then changed the source for sio so that >the sixth probe always returned a successful result. So far I haven't had >any problems more internal modem problems or problems with my other 3 >serial ports. Device drivers are definitely way above my level of >programming skill so what I'm wondering is - Is it likely that I may >create any other problems by doing this? It depends. Failure 6 without failure 5 says that the interrupt went away before it really went away :-). The interrupt handler uses the "real" interrupt bit to decide whether it should loop looking for more things to do. Looping once or twice only adds 5-10% to the serial overhead. >Could adding extra DELAY >statements achieve a similar result more cleanly?? There's already a huge delay of 1000 usec that covers test 6. You might learn how long the interrupt takes to really go away. I guess it doesn't go away. Looping in the interrupt handler for one or two multiples of 1000 usec would increase serial overhead by a large factor. Bruce