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

[Arnaud Lacombe]

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'.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: if_lem.c.diff
Type: application/octet-stream
Size: 1113 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20120728/92bdf67c/if_lem.c.obj