> On Jan 22, 2015, at 6:12 AM, Sorin Vinturis > <svintu...@cloudbasesolutions.com> wrote: > > If the OVS extension was previously enabled and the driver unloaded, > when the driver is loaded again a BSOD is triggered. > > This happens because the OVS extension registers its FilterXxx routines > to NDIS, by calling NdisFRegisterFilterDriver, before performing all > the necessary initialization. Because drivers that call > NdisFRegisterFilterDriver must be prepared for an immediate call to any > of their FilterXxx functions. > > The BSOD is triggered because the FilterAttach routine, OvsExtAttach, > tries to acquire the control lock, when the lock is not yet initialized. > This happens because the FilterAttach is called before the driver > finishes initialization, in OvsInit().
Sorin, Thanks for the patch. This has (had) been an annoying bug. I was wondering if it would be better to just flip the order of OvsCreateDeviceObject() and NdisFRegisterFilterDriver(). If NdisFRegisterFilterDriver() fails, it would be safe to call OvsDeleteDeviceObject(). I don’t have a strong preference, but the change would be make all of the OVS initialization code in one place rather than spread across 2 separate functions. thanks, -- Nithin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
