On Tuesday 06 March 2012 22:30:26 Monthadar Al Jaberi wrote:
> On Tue, Mar 6, 2012 at 9:57 PM, Marko Zec <z...@fer.hr> wrote:
> > 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.
>
> Whats wrong with this line, I am running new kernel remember I compile
> wlan afterward and kldload it
struct ifnet doesn't have a field named if_curvnet, but it does contain a
field named if_vnet.
> it seems to compile fine if I type wrong names inside CURVNET_SET hmm...
No it does not compile.
Marko
> I cant copy/paste db output from VBox butI am attaching two pictures.
>
> > 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"
