On Tuesday 06 March 2012 21:29:32 Monthadar Al Jaberi wrote: > On Tue, Mar 6, 2012 at 9:22 PM, Marko Zec <z...@fer.hr> wrote: > > On Tuesday 06 March 2012 21:13:00 Monthadar Al Jaberi wrote: > >> I am confused so whats the difference between having wlan in kernel > >> config or not? Cuase that seems the reason why we panic... linker > >> problems? > > > > Its not impossible. > > > > Have you tried to do CURVNET_SET(ss->ss_vap->iv_ifp->if_vnet) on entry to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > scan_task() as I suggested earlier in this thread? > > this is the code I added: > diff --git a/sys/net80211/ieee80211_scan.c b/sys/net80211/ieee80211_scan.c > index 5c1e3d9..bd20653 100644 > --- a/sys/net80211/ieee80211_scan.c > +++ b/sys/net80211/ieee80211_scan.c > @@ -850,6 +850,7 @@ scan_task(void *arg, int pending) > int scandone = 0; > > IEEE80211_LOCK(ic); > + CURVNET_SET((struct ieee80211_scan_state *) > ss->ss_vap->iv_ifp->if_curvnet); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You couldn't have ever compiled this, so you must be booting an old kernel. Pls. make sure you have actually rebuilt and rebooted a new kernel, an let us know the outcome. Thanks Marko > if (vap == NULL || (ic->ic_flags & IEEE80211_F_SCAN) == 0 || > (SCAN_PRIVATE(ss)->ss_iflags & ISCAN_ABORT)) { > /* Cancelled before we started */ > @@ -1004,6 +1005,7 @@ scan_task(void *arg, int pending) > ss->ss_ops->scan_restart(ss, vap); /* XXX? */ > ieee80211_runtask(ic, &SCAN_PRIVATE(ss)->ss_scan_task); > IEEE80211_UNLOCK(ic); > + CURVNET_RESTORE(); > return; > } > > @@ -1043,6 +1045,7 @@ done: > SCAN_PRIVATE(ss)->ss_iflags &= ~(ISCAN_CANCEL|ISCAN_ABORT); > ss->ss_flags &= ~(IEEE80211_SCAN_ONCE | IEEE80211_SCAN_PICK1ST); > IEEE80211_UNLOCK(ic); > + CURVNET_RESTORE(); > #undef ISCAN_REP > } > > same panic... > > > Cheers, > > > > Marko > > > >> On Tue, Mar 6, 2012 at 9:06 PM, Adrian Chadd <adrian.ch...@gmail.com> wrote: > >> > Hi, > >> > > >> > The trouble here is that net80211 has quite a few other contexts that > >> > things are called from: > >> > > >> > * driver taskqueue; > >> > * net80211 taskqueue; > >> > * driver callouts; > >> > * net80211 callouts; > >> > * ioctls via net80211. > >> > > >> > That's in parallel with frame tx/rx and device ioctls. > >> > > >> > I don't personally have the time to go through net80211 and driver(s) > >> > at the moment to figure out what's going on. Since ath(4) does a bunch > >> > of frame processing in taskqueue context (and I'm trying to eliminate > >> > frame processing in _callout_ context, ew..) things can potentially > >> > get a bit hairy. > >> > > >> > > >> > Adrian > >> > > >> > On 6 March 2012 11:59, Marko Zec <z...@fer.hr> wrote: > >> >> On Tuesday 06 March 2012 20:49:38 Monthadar Al Jaberi wrote: > >> >>> I added VNET_DEBUG and noticed this warning (original scan_task > >> >>> code): > >> >>> > >> >>> CURVNET_SET() recursion in sosend() line 1350, prev in > >> >>> kern_kldload() 0xfffffe0002202c40 -> 0xfffffe0002202c40 > >> >>> KDB: stack backtrace: > >> >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > >> >>> kdb_backtrace() at kdb_backtrace+0x37 > >> >>> sosend() at sosend+0xbd > >> >>> clnt_vc_call() at clnt_vc_call+0x3e6 > >> >>> clnt_reconnect_call() at clnt_reconnect_call+0xf5 > >> >>> newnfs_request() at newnfs_request+0x9fb > >> >>> nfscl_request() at nfscl_request+0x72 > >> >>> nfsrpc_lookup() at nfsrpc_lookup+0x1be > >> >>> nfs_lookup() at nfs_lookup+0x297 > >> >>> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x95 > >> >>> lookup() at lookup+0x3b8 > >> >>> namei() at namei+0x484 > >> >>> vn_open_cred() at vn_open_cred+0x1e2 > >> >>> link_elf_load_file() at link_elf_load_file+0xb3 > >> >>> linker_load_module() at linker_load_module+0x794 > >> >>> kern_kldload() at kern_kldload+0x145 > >> >>> sys_kldload() at sys_kldload+0x84 > >> >>> amd64_syscall() at amd64_syscall+0x39e > >> >>> Xfast_syscall() at Xfast_syscall+0xf7 > >> >> > >> >> You can safely ignore those. Recursing on curvnet is harmless, but > >> >> in certain cases can't be avoided. > >> >> > >> >> When injecting new CURVNET_SET() / CURVNET_RESTORE() points in the > >> >> existing code, those warnings are here to help us becoming aware that > >> >> we are setting curvnet in a function which was invoked with an > >> >> already valid curvnet context. > >> >> > >> >> Marko _______________________________________________ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"