Date: Sat, 28 Jul 2012 17:41:50 -0400 From: Arnaud Lacombe <lacombar@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: Dimitry Andric <dim@freebsd.org>, current@freebsd.org Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 Message-ID: <CACqU3MWjePb5mswxh6=gMnHG9VF8ezjgtZwX6Ehk8hVo6Y8bog@mail.gmail.com> In-Reply-To: <CAJ-VmomrNdDJKTp8DW5AyffkGEhWvCdu23Q17%2Bm-LnEL-Ujq1g@mail.gmail.com> References: <20120726154610.GC1587@albert.catwhisker.org> <5012E233.3050007@FreeBSD.org> <CAJ-Vmo=Tgg-sYVB5b1RhP0adCYJLrp%2B4W4nvpN6M6giTnBjw7w@mail.gmail.com> <CACqU3MVLuf%2BH-ujVhTqod10uWTioeC0eLgM_fgVHUeH22o55Sg@mail.gmail.com> <CAJ-VmomrNdDJKTp8DW5AyffkGEhWvCdu23Q17%2Bm-LnEL-Ujq1g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--f46d043c80465371b304c5eab254 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Sat, Jul 28, 2012 at 4:04 PM, Adrian Chadd <adrian@freebsd.org> wrote: > On 28 July 2012 12:09, Arnaud Lacombe <lacombar@gmail.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACqU3MWjePb5mswxh6=gMnHG9VF8ezjgtZwX6Ehk8hVo6Y8bog>