On 21 October 2012 12:36, Marko Zec <z...@fer.hr> wrote: > The right approach would be to do a single CURVNET_SET(vnet0) / > CURVNET_RESTORE() somewhere near the root of the call graph being triggered > by the hotplug attach event. Not having any hotpluggable hardware at hand > I cannot be more specific where that place could be...
Right; would that be at the net80211 side, or something higher up (eg at device_attach, which gets called from the cardbus/pci bridge enumeration code.) > But most certainly doing CURVNET_SET(vnet0) on detach events would be wrong: > since ifnets may be assignet to non-default vnets, > CURVNET_SET(ifp->if_vnet) should be more appropriate there. Thanks for that. I'll look at adding that in my next debug pass. > Another thing that may help could be turning on options VNET_DEBUG when, as > that should reveal excessive (and probably redundant) CURVNET_SET() > recursions. I've spotted a couple, however the crashing here is the important bit. :-) So - why is it that the V_* variables are NULL pointers at this stage? I thought the kernel would've been running with a default vnet context of vnet0? Why doesn't this impact other network device hotplugging? Or does it, and noone noticed? Adrian _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
