On Sat, Jul 28, 2012 at 2:41 PM, Arnaud Lacombe <[email protected]> wrote: > Hi, > > On Sat, Jul 28, 2012 at 4:04 PM, Adrian Chadd <[email protected]> wrote: >> On 28 July 2012 12:09, Arnaud Lacombe <[email protected]> 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
fix-if_lem-panic-at-boot.patch
Description: Binary data
_______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]"
