From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 21:41:53 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 578721065670; Sat, 28 Jul 2012 21:41:53 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 892C18FC0A; Sat, 28 Jul 2012 21:41:52 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3610370wgb.31 for ; Sat, 28 Jul 2012 14:41:51 -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=UcYnvR6ypYuXx0tdXJpvRwLMdPAKqaA8eJjcUTFOE3Q=; b=gTMH1FaxZMw3XIXQiLtSfIBQI97HCkKp9xYKkBYCVQYlkpYfSQwQXxt823xN0sz1UB qjFKYWi7n+a0WVgpi+eGUeUdoo5KRz4gPn+XXcLYHEqo0jTx+vCNcSwpoeMLzf3vdv/V kI3Pp+bukC55VJbcDSAyPc4of1kzfQJ6vR0jf8VBFEiOj4K9VBvjCWsYkbvatESq3TJx st+y5MuZHQ6g3H1+WieN5zVDgTdF2lry5epkCX3yOoRkHMbJU7Ay4i1kJyFrM2H1I6My M7yd8ljuOe7hyZHOHfp+CkCVhTHzPL5Fs8PZ+5u2W7IPKgL5SmhkNiVaSqfSCbfVANKE gMUw== MIME-Version: 1.0 Received: by 10.180.90.207 with SMTP id by15mr31116096wib.22.1343511711674; Sat, 28 Jul 2012 14:41:51 -0700 (PDT) Received: by 10.216.199.31 with HTTP; Sat, 28 Jul 2012 14:41:50 -0700 (PDT) In-Reply-To: References: <20120726154610.GC1587@albert.catwhisker.org> <5012E233.3050007@FreeBSD.org> Date: Sat, 28 Jul 2012 17:41:50 -0400 Message-ID: From: Arnaud Lacombe To: Adrian Chadd Content-Type: multipart/mixed; boundary=f46d043c80465371b304c5eab254 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 21:41:53 -0000 --f46d043c80465371b304c5eab254 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Sat, Jul 28, 2012 at 4:04 PM, Adrian Chadd wrote: > On 28 July 2012 12:09, Arnaud Lacombe wrote: > >> 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. > > Take a look at iwn. It has a single lock - IWN_LOCK() - which it > releases before punting the frame up the stack. > oh, I see. So, what happens in lem(4) is that we enter the stack with RX unlocked, but TX and CORE are still locked. The whole locking of lem(4) seems rather inconsistent. Through DEVICE_POLLING, lem_rxeof() is called with TX and CORE unlocked. Through EN_LEGACY_IRQ it is called with TX and CORE locked, and from MSI interrupt handler, is is caller with TX unlocked (CORE assumed to be unlock). I'd assume that lem(4) is just poorly maintained[0]... I would make a huge shot in the dark by proposing the completely untested attached patch :/ - Arnaud [0]: like code claiming support for Intel 82574 when this chipset *cannot* be used by lem(4), as there is no E1000_DEV_ID_82574* entries in `lem_vendor_info_array'. --f46d043c80465371b304c5eab254 Content-Type: application/octet-stream; name="if_lem.c.diff" Content-Disposition: attachment; filename="if_lem.c.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h5785h3b0 ZGlmZiAtLWdpdCBhL3N5cy9kZXYvZTEwMDAvaWZfbGVtLmMgYi9zeXMvZGV2L2UxMDAwL2lmX2xl bS5jCmluZGV4IDRhZGUxODAuLjE1OTZkNjYgMTAwNjQ0Ci0tLSBhL3N5cy9kZXYvZTEwMDAvaWZf bGVtLmMKKysrIGIvc3lzL2Rldi9lMTAwMC9pZl9sZW0uYwpAQCAtMTMwNCwxMSArMTMwNCwxNSBA QCBsZW1faW50cih2b2lkICphcmcpCiAJaWYgKHJlZ19pY3IgJiBFMTAwMF9JQ1JfUlhPKQogCQlh ZGFwdGVyLT5yeF9vdmVycnVucysrOwogCi0JaWYgKChyZWdfaWNyID09IDB4ZmZmZmZmZmYpIHx8 IChyZWdfaWNyID09IDApKQotCQkJZ290byBvdXQ7CisJaWYgKChyZWdfaWNyID09IDB4ZmZmZmZm ZmYpIHx8IChyZWdfaWNyID09IDApKSB7CisJCUVNX0NPUkVfVU5MT0NLKGFkYXB0ZXIpOworCQln b3RvIG91dDsKKwl9CiAKLQlpZiAoKGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5H KSA9PSAwKQotCQkJZ290byBvdXQ7CisJaWYgKChpZnAtPmlmX2Rydl9mbGFncyAmIElGRl9EUlZf UlVOTklORykgPT0gMCkgeworCQlFTV9DT1JFX1VOTE9DSyhhZGFwdGVyKTsKKwkJZ290byBvdXQ7 CisJfQogCiAJaWYgKHJlZ19pY3IgJiAoRTEwMDBfSUNSX1JYU0VRIHwgRTEwMDBfSUNSX0xTQykp IHsKIAkJY2FsbG91dF9zdG9wKCZhZGFwdGVyLT50aW1lcik7CkBAIC0xMzIwLDE3ICsxMzI0LDE3 IEBAIGxlbV9pbnRyKHZvaWQgKmFyZykKIAkJICAgIGxlbV9sb2NhbF90aW1lciwgYWRhcHRlcik7 CiAJCWdvdG8gb3V0OwogCX0KKwlFTV9DT1JFX1VOTE9DSyhhZGFwdGVyKTsKIAotCUVNX1RYX0xP Q0soYWRhcHRlcik7CiAJbGVtX3J4ZW9mKGFkYXB0ZXIsIC0xLCBOVUxMKTsKKworCUVNX1RYX0xP Q0soYWRhcHRlcik7CiAJbGVtX3R4ZW9mKGFkYXB0ZXIpOwotCWlmIChpZnAtPmlmX2Rydl9mbGFn cyAmIElGRl9EUlZfUlVOTklORyAmJgotCSAgICAhSUZRX0RSVl9JU19FTVBUWSgmaWZwLT5pZl9z bmQpKQorCWlmICghSUZRX0RSVl9JU19FTVBUWSgmaWZwLT5pZl9zbmQpKQogCQlsZW1fc3RhcnRf bG9ja2VkKGlmcCk7CiAJRU1fVFhfVU5MT0NLKGFkYXB0ZXIpOwogCiBvdXQ6Ci0JRU1fQ09SRV9V TkxPQ0soYWRhcHRlcik7CiAJcmV0dXJuOwogfQogCg== --f46d043c80465371b304c5eab254--