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'.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:29 UTC