Date: Tue, 6 Mar 2012 21:29:32 +0100 From: Monthadar Al Jaberi <monthadar@gmail.com> To: Marko Zec <zec@fer.hr> Cc: Adrian Chadd <adrian.chadd@gmail.com>, freebsd-virtualization@freebsd.org Subject: Re: VIMAGE + kldload wlan + kldload wtap panic Message-ID: <CA%2BsBSo%2BzG%2BF1c3xhtTiAOagyseGP=17Vd4zLGYaTj-pqgoXAtA@mail.gmail.com> In-Reply-To: <201203062122.15426.zec@fer.hr> 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> <201203062122.15426.zec@fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 6, 2012 at 9:22 PM, Marko Zec <zec@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 =3D 0;
IEEE80211_LOCK(ic);
+ CURVNET_SET((struct ieee80211_scan_state *)
ss->ss_vap->iv_ifp->if_curvnet);
if (vap =3D=3D NULL || (ic->ic_flags & IEEE80211_F_SCAN) =3D=3D 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 &=3D ~(ISCAN_CANCEL|ISCAN_ABORT);
ss->ss_flags &=3D ~(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.chadd@gmail.com> wr=
ote:
>> > 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
>
>
--=20
Monthadar Al Jaberi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BsBSo%2BzG%2BF1c3xhtTiAOagyseGP=17Vd4zLGYaTj-pqgoXAtA>