From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 22:39:43 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB2DB106566B; Sat, 28 Jul 2012 22:39:42 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7B29C8FC0A; Sat, 28 Jul 2012 22:39:42 +0000 (UTC) Received: by obbun3 with SMTP id un3so8335197obb.13 for ; Sat, 28 Jul 2012 15:39:41 -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=UrEPqv4vSV1aD7TQbyDYTGF/pQTBXc7YdYhMqRA8W60=; b=zcM4W//GOX9GjVdYujnVOkFXR+Eble6csbcuWnRpj+A2yTZP2OlHck8FMDizCN6r1e r44aDLfme1ArU1idvTSMXZ71a++N05BrDu4QZUUquZQh/BBQqp+C5ytd9F0SAD7AeRUM QR6E5FNYKSN3+ElZvDhaxrkFh6dNhLEavjTCvtxuO6bDQhkrkbQBJGr1w1TT4pnlfXQd cPkcNFGXKBaTOtDhdWb3ulvGTCvRLZnaTraODFOvTW4V52Uk26ht0ho0Jr17TWIPAgFn uMhK8kmOsWdokTXNm/Yts6NEf60sGvngqmuZ0QaCUwfSAq5T5o0enq60xwHiA8ik9MRc YFVA== MIME-Version: 1.0 Received: by 10.182.8.6 with SMTP id n6mr10246829oba.39.1343515181878; Sat, 28 Jul 2012 15:39:41 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Sat, 28 Jul 2012 15:39:41 -0700 (PDT) In-Reply-To: References: <20120726154610.GC1587@albert.catwhisker.org> <5012E233.3050007@FreeBSD.org> Date: Sat, 28 Jul 2012 15:39:41 -0700 Message-ID: From: Garrett Cooper To: Arnaud Lacombe Content-Type: multipart/mixed; boundary=f46d0444ec532a8c8c04c5eb81f7 Cc: Adrian Chadd , 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 22:39:43 -0000 --f46d0444ec532a8c8c04c5eb81f7 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 28, 2012 at 2:41 PM, Arnaud Lacombe wrote: > 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'. Close, but you missed a spot. The attached patch (based on your's) works, i.e. no longer panics at boot on my vbox instance. Thanks! -Garrett --f46d0444ec532a8c8c04c5eb81f7 Content-Type: application/octet-stream; name="fix-if_lem-panic-at-boot.patch" Content-Disposition: attachment; filename="fix-if_lem-panic-at-boot.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h57a8juz1 LS0tIC8vZGVwb3QvdXNlci9nY29vcGVyL2F0Zi1oZWFkL3NyYy9zeXMvZGV2L2UxMDAwL2lmX2xl bS5jCTIwMTItMDctMjUgMTc6MTE6MDAuMDAwMDAwMDAwIDAwMDAKKysrIC9zY3JhdGNoL3A0L3Vz ZXIvZ2Nvb3Blci9hdGYtaGVhZC9zcmMvc3lzL2Rldi9lMTAwMC9pZl9sZW0uYwkyMDEyLTA3LTI1 IDE3OjExOjAwLjAwMDAwMDAwMCAwMDAwCkBAIC0xMjk0LDEyICsxMjk0LDEzIEBACiAJc3RydWN0 IGFkYXB0ZXIJKmFkYXB0ZXIgPSBhcmc7CiAJc3RydWN0IGlmbmV0CSppZnAgPSBhZGFwdGVyLT5p ZnA7CiAJdTMyCQlyZWdfaWNyOwotCisJaW50IGxvY2tlZDsKIAogCWlmIChpZnAtPmlmX2NhcGVu YWJsZSAmIElGQ0FQX1BPTExJTkcpCiAJCXJldHVybjsKIAogCUVNX0NPUkVfTE9DSyhhZGFwdGVy KTsKKwlsb2NrZWQgPSAxOwogCXJlZ19pY3IgPSBFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcs IEUxMDAwX0lDUik7CiAJaWYgKHJlZ19pY3IgJiBFMTAwMF9JQ1JfUlhPKQogCQlhZGFwdGVyLT5y eF9vdmVycnVucysrOwpAQCAtMTMyMCw5ICsxMzIxLDExIEBACiAJCSAgICBsZW1fbG9jYWxfdGlt ZXIsIGFkYXB0ZXIpOwogCQlnb3RvIG91dDsKIAl9CisJRU1fQ09SRV9VTkxPQ0soYWRhcHRlcik7 CisJbG9ja2VkID0gMDsKIAorCWxlbV9yeGVvZihhZGFwdGVyLCAtMSwgTlVMTCk7CiAJRU1fVFhf TE9DSyhhZGFwdGVyKTsKLQlsZW1fcnhlb2YoYWRhcHRlciwgLTEsIE5VTEwpOwogCWxlbV90eGVv ZihhZGFwdGVyKTsKIAlpZiAoaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcgJiYK IAkgICAgIUlGUV9EUlZfSVNfRU1QVFkoJmlmcC0+aWZfc25kKSkKQEAgLTEzMzAsNyArMTMzMyw5 IEBACiAJRU1fVFhfVU5MT0NLKGFkYXB0ZXIpOwogCiBvdXQ6Ci0JRU1fQ09SRV9VTkxPQ0soYWRh cHRlcik7CisJaWYgKGxvY2tlZCkKKwkJRU1fQ09SRV9VTkxPQ0soYWRhcHRlcik7CisKIAlyZXR1 cm47CiB9CiAK --f46d0444ec532a8c8c04c5eb81f7--