cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h

[M. Warner Losh]

> 	fxp_detach()
> [4]	LOCK
> [a]	write 0 to dis intr
> [5]				device B on same intr interrupts here
> 				fxp_intr()
> 				LOCK (->sleep)
> [b]	gone = 0;
> 	UNLOCK
> [1]				if (gone) return;
> [2]	bus_teardown_intr();
> [3]	bus_teardown_intr returns

In message: <3EB14AE8.1040902 at btc.adaptec.com>
            Scott Long <scott_long at btc.adaptec.com> writes:
: In this example, is there a reason for the fxp ISR to hold the mutex
: before it determines the source of the interrupt?

The interrupt could well be for the fxp card, between points [4] and
[a], so it would read the ISR source register, see that it is his and
take the lock out.  That's slightly different than my example, but
still a concern.  Doug Rabson has reported, when doing the initial
ia64 port, that races of even one instruction in width were observed
to have happened.

Warner