From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 15:47:23 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 9D79816A4D2; Mon, 16 Aug 2004 15:47:23 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2565E43D1F; Mon, 16 Aug 2004 15:47:23 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7GFiHil061349; Mon, 16 Aug 2004 09:44:17 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 16 Aug 2004 09:44:38 -0600 (MDT) Message-Id: <20040816.094438.104354000.imp@bsdimp.com> To: green@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20040816153437.GJ980@green.homeunix.org> References: <20040717182841.GR1626@green.homeunix.org> <20040717.124803.33210527.imp@bsdimp.com> <20040816153437.GJ980@green.homeunix.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: current@FreeBSD.org cc: jhb@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:47:23 -0000 In message: <20040816153437.GJ980@green.homeunix.org> Brian Fundakowski Feldman writes: : 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 think the day of code freeze makes this too late. : 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. I already fixed this. At least on my machine. The races that you pointed out have been corrected. Have you tested it recently? It works for me w/o any problems, but I'll spend some time today. : 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). I don't think we need this. The lists are already protected by mutexes. The problems you pointed out were in how the pccbb layer was bogusly handling things. Since I've merged the fixes into -current already, I don't see a need for the above. So I claim there's no problems with completely up to date sources. I'll test this claim later today on my laptop (I'll try it after the buildworld is done), but I'm pretty sure I tested it before putting it in p4. : Comments, please. Too late. Warner