From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 15:34:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AC2216A4CE; Mon, 16 Aug 2004 15:34:42 +0000 (GMT) Received: from green.homeunix.org (pcp04371970pcs.nrockv01.md.comcast.net [69.140.223.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94D4243D45; Mon, 16 Aug 2004 15:34:41 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i7GFYcOb025861; Mon, 16 Aug 2004 11:34:38 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i7GFYcmA025860; Mon, 16 Aug 2004 11:34:38 -0400 (EDT) (envelope-from green) Date: Mon, 16 Aug 2004 11:34:37 -0400 From: Brian Fundakowski Feldman To: "M. Warner Losh" , jhb@FreeBSD.org Message-ID: <20040816153437.GJ980@green.homeunix.org> References: <20040717054014.GP1626@green.homeunix.org> <20040717.121712.83689795.imp@bsdimp.com> <20040717182841.GR1626@green.homeunix.org> <20040717.124803.33210527.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040717.124803.33210527.imp@bsdimp.com> User-Agent: Mutt/1.5.6i cc: current@FreeBSD.org Subject: Re: pccbb crashes when detaching (unsafe interrupt handler) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2004 15:34:42 -0000 Can we start off again on a good foot so we can fix this before -STABLE? I think, at a very very low cost (instruction cache bloat, but few extra instructions in the fast-path), we can implement suspension of ithread handlers. This would completely solve the problem at hand, and all the "slowness" would be pushed onto the ithread munging calls. I get an immediate panic when running X and unloading a card on my notebook because they share interrupts. I get an immediate panic on eject and kldunload, the exact same case, on my desktop when I'm playing music and interrupts are shared between the cardbus and the sound card. I don't think there would be harm pausing the interrupt handler to create a critical section there. That is, it_need would be cleared, ih_need would be cleared and unsuspended interrupt handlers run, suspended interrupt handlers acknowledged and then run once they become unsuspended. Where IH_DEAD is checked would be added the test for suspension and acknowledgement. We could use the mutex to synchronize the ithread suspension function by setting a flag IH_WANTSUSPEND, use a flag IH_SUSPENDED to mark it suspended, and only allow a single suspension at a time (the ithread suspender would have to sleep until it can grab IH_WANTSUSPEND). The cost would be nil (testing (IH_DEAD | IH_*SUSPEND*) instead of IH_DEAD) plus one store and load (stack variable initialized to 0 for "need to run suspended handlers" after they have been iterated through the first time). Comments, please. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\