Re: How to catch interrupt

From: Bruce Evans <bde_at_zeta.org.au>
Date: Fri, 18 Jun 2004 09:50:35 +1000 (EST)
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
Received on Thu Jun 17 2004 - 21:51:35 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:57 UTC