From owner-freebsd-current@FreeBSD.ORG Tue Oct 26 16:50:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D504106566C for ; Tue, 26 Oct 2010 16:50:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3A4EE8FC17 for ; Tue, 26 Oct 2010 16:50:19 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E3DF546B0D; Tue, 26 Oct 2010 12:50:18 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 895B88A01D; Tue, 26 Oct 2010 12:50:17 -0400 (EDT) From: John Baldwin To: Matthew Fleming Date: Tue, 26 Oct 2010 12:46:42 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010261246.42238.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 26 Oct 2010 12:50:17 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: intr_event_destroy(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Tue, 26 Oct 2010 16:50:21 -0000 On Tuesday, October 26, 2010 11:55:10 am Matthew Fleming wrote: > It looks like a bug in intr_event_destroy(9): I'm trying to unload a > new driver being developed internally for NVRAM, and I get this > WITNESS warning and hang: > > > # kldunload rnv > Sleeping on "ithdty" with the following non-sleepable locks held: > exclusive sleep mutex intr event list (intr event list) r = 0 > (0xffffffff806f9560) locked @ > /data/sb/BR_BONNEVILLE_HW/src/sys/kern/kern_intr.c:404 > KDB: stack backtrace: > [ffffffff801a544d] db_trace_self_wrapper+0x3d > [ffffffff802e7b26] witness_warn+0x2f6 > [ffffffff802a1a43] _sleep+0xc3 > [ffffffff8026dad5] intr_event_destroy+0xe5 > [ffffff87b05ba805] rnv_pci_detach+0xc5 > [ffffffff802c9414] device_detach+0xb4 > [ffffffff802c974f] devclass_delete_driver+0xdf > [ffffffff802c991d] driver_module_handler+0x11d > [ffffffff802843a2] module_unload+0x42 > [ffffffff80279f4b] linker_file_unload+0x19b > [ffffffff8027aa1b] kern_kldunload+0x10b > [ffffffff802a2609] isi_syscall+0x99 > [ffffffff804dee3e] ia32_syscall+0x1ce > [ffffffff804a7e50] Xint0x80_syscall+0x60 > --- syscall (444, FreeBSD ELF32, kldunloadf), rip = 0x280c1aff, rsp = > 0xffffd44c, rbp = 0xffffdc98 --- > > Looking at intr_event_destroy, I see this snippet from r157728: > > > #ifndef notyet > if (ie->ie_thread != NULL) { > ithread_destroy(ie->ie_thread); > ie->ie_thread = NULL; > } > #endif > > There is an msleep(9) in ithread_destroy(9). And everywhere else that > uses notyet has #ifdef, not #ifndef. So... is this a typo? No, it's actually on purpose I think as the other bits under notyet destroy the thread when the last handler for it goes away. However, ithread_destroy() does not block in any of 7.x or later: static void ithread_destroy(struct intr_thread *ithread) { struct thread *td; CTR2(KTR_INTR, "%s: killing %s", __func__, ithread->it_event->ie_name); td = ithread->it_thread; thread_lock(td); ithread->it_flags |= IT_DEAD; if (TD_AWAITING_INTR(td)) { TD_CLR_IWAIT(td); sched_add(td, SRQ_INTR); } thread_unlock(td); } Maybe you have a local change? If so, you can probably unlock the global event_list lock before calling ithread_destroy() (but after the TAILQ_REMOVE()) in intr_event_destroy(). -- John Baldwin