Date: Sat, 28 Jul 2012 15:39:41 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: Arnaud Lacombe <lacombar@gmail.com> Cc: Adrian Chadd <adrian@freebsd.org>, 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: <CAGH67wT_YaXyEkAAWvQ54ro2MFBiMvbo-vWx592BmG0p6CNpKw@mail.gmail.com> In-Reply-To: <CACqU3MWjePb5mswxh6=gMnHG9VF8ezjgtZwX6Ehk8hVo6Y8bog@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> <CACqU3MWjePb5mswxh6=gMnHG9VF8ezjgtZwX6Ehk8hVo6Y8bog@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--f46d0444ec532a8c8c04c5eb81f7
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Jul 28, 2012 at 2:41 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> 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'.
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGH67wT_YaXyEkAAWvQ54ro2MFBiMvbo-vWx592BmG0p6CNpKw>