Date: Tue, 6 Mar 2012 21:22:15 +0100 From: Marko Zec <zec@fer.hr> To: freebsd-virtualization@freebsd.org Cc: Adrian Chadd <adrian.chadd@gmail.com> Subject: Re: VIMAGE + kldload wlan + kldload wtap panic Message-ID: <201203062122.15426.zec@fer.hr> In-Reply-To: <CA%2BsBSoL7xZQE=Eyofp32haG0Wn_WnZeWrGHKZcmM0za2gdns%2BQ@mail.gmail.com> References: <CA%2BsBSo%2Bt=p0HLbyOH87DOJWWYn%2Be%2Bok7cwRiL1c1=gCw5=KTqg@mail.gmail.com> <CAJ-VmokH8j_8JVYyhyBVH-8csD6vG28eeUO48dW1_Q7QFo59mA@mail.gmail.com> <CA%2BsBSoL7xZQE=Eyofp32haG0Wn_WnZeWrGHKZcmM0za2gdns%2BQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=20 scan_task() as I suggested earlier in this thread? Cheers, Marko > On Tue, Mar 6, 2012 at 9:06 PM, Adrian Chadd <adrian.chadd@gmail.com> wro= te: > > 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 <zec@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() > >>> =A0 =A0 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. =A0Recursing 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203062122.15426.zec>