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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030501.110833.25163273.imp>