panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881

[Garrett Cooper]

On Sat, Jul 28, 2012 at 2:41 PM, Arnaud Lacombe <lacombar at gmail.com> wrote:
> Hi,
>
> On Sat, Jul 28, 2012 at 4:04 PM, Adrian Chadd <adrian at freebsd.org> wrote:
>> On 28 July 2012 12:09, Arnaud Lacombe <lacombar at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-if_lem-panic-at-boot.patch
Type: application/octet-stream
Size: 977 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20120728/243f8eeb/fix-if_lem-panic-at-boot.obj