From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 19:09:54 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 708DD106567E; Sat, 28 Jul 2012 19:09:54 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A7B418FC08; Sat, 28 Jul 2012 19:09:53 +0000 (UTC) Received: by weyx56 with SMTP id x56so3308688wey.13 for ; Sat, 28 Jul 2012 12:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DCHc3mQ6nHfZfbetpT3cFG0bg3Nd5FcEIc2IxBDz7wY=; b=kbMREAj+yx3nl7c7ma3akoTjp+wNSunPqr/LNk/KoypIgAvlHjs2FgY0YBOPT1plbd l1KeZRdPVNeUVz0vpvaKhwPvZVY9vsdu64R40ewQbwhHR/kzPyXfuuYP3J8FFljBRVQk HoxJLI3eo2EDj9zgMOFDPEvITE7tH4GPbZCzeDHZjVQ/D4K0Kkmw23LoBV/tChVWDNOd L8Xz3fgpsUuDZUhAoT6g0R95kFNxaD8LDEqmhHklpZCvxCUYvC7vT5VerqV27nlhcTI0 cuH46qz9BSm0Bz+2utYbV+C5CUjgGB4biecVUtnMvx1Jxpi7BvkV9lHdChhaE5E9lUnO qOoA== MIME-Version: 1.0 Received: by 10.180.91.1 with SMTP id ca1mr30980584wib.8.1343502587383; Sat, 28 Jul 2012 12:09:47 -0700 (PDT) Received: by 10.216.199.31 with HTTP; Sat, 28 Jul 2012 12:09:47 -0700 (PDT) In-Reply-To: References: <20120726154610.GC1587@albert.catwhisker.org> <5012E233.3050007@FreeBSD.org> Date: Sat, 28 Jul 2012 15:09:47 -0400 Message-ID: From: Arnaud Lacombe To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Dimitry Andric , current@freebsd.org Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 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: Sat, 28 Jul 2012 19:09:54 -0000 Hi, On Fri, Jul 27, 2012 at 4:31 PM, Adrian Chadd wrote: > It looks like a case of "lock held during call up the stack". This is > bad for so many reasons. > > It also makes writing correctly locked drivers a pain in the ass as > the moment you unlock the driver before calling ether_input() / > ieee80211_input(), you allow things to change state. So no, although > you shouldn't use long-held locks to protect things, apparently this > is all the rage. > > iwn(4) does this. ath(4) does not. I'm having a right painful time > trying to fine-grain lock things. I'm at the point where I'm about to > not care, rip out all the locks and replace with a single ATH_LOCK(). > How would a single ATH_LOCK() helps here ? AFAICS, the panic seem to be a classical fallout from direct dispatch where you can re-enter the driver from the driver itself through the network stack. - Arnaud > Adrian > > On 27 July 2012 11:47, Dimitry Andric wrote: >> On 2012-07-26 17:46, David Wolfskill wrote: >>> This is at r238795; cut/paste of backtrace: >>> >>> KDB: enter: panic >>> [ thread pid 12 tid 100026 ] >>> Stopped at kdb_enter+0x3d: movl $0,kdb_why >>> db> bt >>> Tracing pid 12 tid 100026 td 0xc6755000 >>> kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x3d >>> panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4 >>> _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at _mtx_lock_sleep+0x35e >>> _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb >>> lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33 >>> if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129 >>> ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df >>> arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c >>> netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at netisr_dispatch_src+0xa7 >>> netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20 >>> ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133 >>> ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at ether_nh_input+0x329 >>> netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7 >>> netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20 >>> ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21 >>> lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567 >>> intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at intr_event_execute_handlers+0xc5 >>> ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2 >>> fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c >>> fork_trampoline() at fork_trampoline+0x8 >>> --- trap 0, eip = 0, esp = 0xf0839d40, ebp = 0 --- >>> db> show locks >>> exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc68b8560) locked @ /usr/src/sys/dev/e1000/if_lem.c:1324 >>> exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xc68b854c) locked @ /usr/src/sys/dev/e1000/if_lem.c:1302 >>> db> >>> >>> I need to head off to a meeting; I can poke at the machine a bit more >>> in a couple of hours or so. >> >> I get the same panic and backtrace here, while running as a VMware >> guest. At least, as soon something actually happens with the network. >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"