From owner-cvs-all@FreeBSD.ORG Thu May 1 09:38:48 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D535D37B401; Thu, 1 May 2003 09:38:48 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEC5043F85; Thu, 1 May 2003 09:38:45 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h41GZaZ07259; Thu, 1 May 2003 09:35:36 -0700 Received: from btc.btc.adaptec.com ([10.100.0.52]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id JAA15034; Thu, 1 May 2003 09:38:32 -0700 (PDT) Received: from [10.100.253.70] (aslan [10.100.253.70]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id KAA03370; Thu, 1 May 2003 10:38:29 -0600 (MDT) Date: Thu, 01 May 2003 10:38:30 -0600 From: "Justin T. Gibbs" To: "M. Warner Losh" Message-ID: <1742240000.1051807110@aslan.btc.adaptec.com> In-Reply-To: <20030501.101409.57443470.imp@bsdimp.com> References: <1721460000.1051803729@aslan.btc.adaptec.com> <20030501.101409.57443470.imp@bsdimp.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: jhb@freebsd.org cc: gallatin@cs.duke.edu Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Justin T. Gibbs" List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 16:38:49 -0000 > : All doable things for all but really broken hardware. fxp is not broken. > > The whole reason for the gone flag may be misunderstood here. You can > easily turn off the fxp device, and there will be no more interrupts > from it. However, its ISR can and will still be called from time to > time until the bus_teardown_intr() is complete? Why you ask? No, I didn't ask. The same applies to *any* driver that can share interrupts. This includes ahc and ahd. I just assumed that the interrupt handler could determine that the interrupt was not for it regardless of whether or not the card is generating interrupts. > 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 > > > [1] and [2] can happen in any order, but you know both of them have > happened by [3]. This is true regardless of whether or not you have a gone flag. The interrupt handler will not be executing by the time bus_teardown_intr() returns. This is all that is required. > The order of [a] and [b] don't really matter because fxp (or anything > that shares its interrupt) could generate an interrupt after the lock > is taken out at [4] and you'd still have a fxp_intr sleeping thread. And that thread can wakeup as soon as you release your lock. You simply cannot call bus_teardown_intr() with a lock held. Ever. > This might argue for blocking interrupts during a device detach. I > think there might be problems with that apprach as well, although I'd > have to think about it a bit to be sure. I don't see that there is any problem with the above approach (it is the same flow as is used by the ahc and ahd driver) but I still don't see why a gone flag is required. Just run through the handler as you normally would in the shared interrupt case. The handler will exit if written correctly. -- Justin