VIMAGE + kldload wlan + kldload wtap panic

[Monthadar Al Jaberi]

On Tue, Mar 6, 2012 at 9:57 PM, Marko Zec <zec at 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 <zec at 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

it seems to compile fine if I type wrong names inside CURVNET_SET hmm...

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.chadd at 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 <zec at 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
>
>



-- 
Monthadar Al Jaberi