Date: Thu, 01 May 2003 11:08:33 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: scott_long@btc.adaptec.com Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h Message-ID: <20030501.110833.25163273.imp@bsdimp.com> In-Reply-To: <3EB14AE8.1040902@btc.adaptec.com> References: <1721460000.1051803729@aslan.btc.adaptec.com> <20030501.101409.57443470.imp@bsdimp.com> <3EB14AE8.1040902@btc.adaptec.com>
index | next in thread | previous in thread | raw e-mail
> 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@btc.adaptec.com>
Scott Long <scott_long@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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030501.110833.25163273.imp>