From owner-freebsd-current@FreeBSD.ORG Fri Jun 18 12:44:50 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 E159516A4CE for ; Fri, 18 Jun 2004 12:44:50 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 210F843D49 for ; Fri, 18 Jun 2004 12:44:50 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i5ICf4TG042838 for freebsd-current@freebsd.org.checked; (8.12.8/vak/2.1) Fri, 18 Jun 2004 16:41:04 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i5ICcwu5042745; (8.12.8/vak/2.1) Fri, 18 Jun 2004 16:38:58 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <40D2E22A.40702@cronyx.ru> Date: Fri, 18 Jun 2004 16:38:02 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Evans References: <40D070B7.5000009@cronyx.ru> <20040617080547.F8883@gamplex.bde.org> <40D0CABA.1020101@cronyx.ru> <20040617164703.H2144@gamplex.bde.org> <40D1D2A8.2070000@cronyx.ru> <20040618093024.X1609@gamplex.bde.org> In-Reply-To: <20040618093024.X1609@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 18 Jun 2004 12:44:51 -0000 Ok. Thanks for information. I guess I need to remove this code from my driver. This code is part of cx(4) and ctau(4) drivers. These cards are legacy ISA cards, IRQ line could be set any (from a definite set). The only reason why we probe for IRQ is to write to the user messages that IRQ is not functional - most probable it is assigned fot PCI/PNP. After we add this code calls to our tech support with question why device is not working (due to this reason) decreased twice. rik Bruce Evans wrote: >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 > > > >