Date: Fri, 18 Jun 2004 16:38:02 +0400 From: Roman Kurakin <rik@cronyx.ru> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-current@freebsd.org Subject: Re: How to catch interrupt Message-ID: <40D2E22A.40702@cronyx.ru> In-Reply-To: <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> <20040618093024.X1609@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40D2E22A.40702>