Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Mar 2012 21:13:00 +0100
From:      Monthadar Al Jaberi <monthadar@gmail.com>
To:        Adrian Chadd <adrian.chadd@gmail.com>
Cc:        Marko Zec <zec@fer.hr>, freebsd-virtualization@freebsd.org
Subject:   Re: VIMAGE + kldload wlan + kldload wtap panic
Message-ID:  <CA%2BsBSoL7xZQE=Eyofp32haG0Wn_WnZeWrGHKZcmM0za2gdns%2BQ@mail.gmail.com>
In-Reply-To: <CAJ-VmokH8j_8JVYyhyBVH-8csD6vG28eeUO48dW1_Q7QFo59mA@mail.gmail.com>
References:  <CA%2BsBSo%2Bt=p0HLbyOH87DOJWWYn%2Be%2Bok7cwRiL1c1=gCw5=KTqg@mail.gmail.com> <CAJ-VmomY7ipsvok1pACjPU-Y933uTTiZ5-6EZG0B=Ofw226owg@mail.gmail.com> <CA%2BsBSoJUmzmOJmN8PvjfPTUDnez7MCHU9GvYpLNqER94haxk=g@mail.gmail.com> <201203062059.31736.zec@fer.hr> <CAJ-VmokH8j_8JVYyhyBVH-8csD6vG28eeUO48dW1_Q7QFo59mA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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?

On Tue, Mar 6, 2012 at 9:06 PM, Adrian Chadd <adrian.chadd@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@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 exist=
ing
>> code, those warnings are here to help us becoming aware that we are sett=
ing
>> 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%2BsBSoL7xZQE=Eyofp32haG0Wn_WnZeWrGHKZcmM0za2gdns%2BQ>