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
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?
> 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
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to