From owner-freebsd-current@FreeBSD.ORG Thu Jun 17 23:51:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F7CB16A4CE for ; Thu, 17 Jun 2004 23:51:35 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 241FF43D55 for ; Thu, 17 Jun 2004 23:51:35 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i5HNoc5v012673; Fri, 18 Jun 2004 09:50:38 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i5HNoaaU014801; Fri, 18 Jun 2004 09:50:37 +1000 Date: Fri, 18 Jun 2004 09:50:35 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Roman Kurakin In-Reply-To: <40D1D2A8.2070000@cronyx.ru> Message-ID: <20040618093024.X1609@gamplex.bde.org> References: <40D070B7.5000009@cronyx.ru> <20040617080547.F8883@gamplex.bde.org> <40D0CABA.1020101@cronyx.ru> <20040617164703.H2144@gamplex.bde.org> <40D1D2A8.2070000@cronyx.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: How to catch interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2004 23:51:35 -0000 On Thu, 17 Jun 2004, Roman Kurakin wrote: > Bruce Evans wrote: > > [using isa_irq_pending()] > > > So spin lock should help me in some cases but there is other cases were > this wouldn't help or I miss > smth? Right. isa_irq_pending() only works right for isa devices at boot time (not for probing later). > In this case if some driver will acquire interrupt while probing > and after this it will release it > (for example it will decide that this is wrong intr and will try other), > and after we will try to load > sio driver we may fail to load it case we would unable to check this > intr line. sio only uses this mechanism to print a helpful (?) message about which irqs it found. It gives priority to the irq resource. There's really nothing better than actually setting up the irq and seeing if one arrives. sio doesn't do this mainly because when it was written its probe was run before interrupts are fully unmasked (they were blocked by splhigh() until the end of isa_configure()). npx used to have the same problem, but I changed it to use bus_setup_intr() normally. This caused new problems which were only fixed recently in npx and are unfixed at lower levels. The interrupt system still leaves edge triggered interrupt active after bus_teardown_intr(). If you don't know the irq number and don't trust the irq resource to give it, then there seems to be nothing better than trying all irq numbers until your irq is found or bus_setup_intr() fails. There can be up to 193 (?) possible irq numbers on i386's. Bruce