Date: Tue, 6 Mar 2012 20:49:38 +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%2BsBSoJUmzmOJmN8PvjfPTUDnez7MCHU9GvYpLNqER94haxk=g@mail.gmail.com> In-Reply-To: <CAJ-VmomY7ipsvok1pACjPU-Y933uTTiZ5-6EZG0B=Ofw226owg@mail.gmail.com> References: <CA%2BsBSo%2Bt=p0HLbyOH87DOJWWYn%2Be%2Bok7cwRiL1c1=gCw5=KTqg@mail.gmail.com> <201203060052.28603.zec@fer.hr> <CA%2BsBSoJJbsrCCp-GzZOJU-gMjDYsM4UX0fj5no-5%2BazThq0_Kg@mail.gmail.com> <201203061633.03446.zec@fer.hr> <CAJ-VmomY7ipsvok1pACjPU-Y933uTTiZ5-6EZG0B=Ofw226owg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
On Tue, Mar 6, 2012 at 7:01 PM, Adrian Chadd <adrian.chadd@gmail.com> wrote:
> Hi,
>
> What do we need to do to get VNET working in net80211 and the network drivers?
>
>
> Adrian
>
> On 6 March 2012 07:33, Marko Zec <zec@fer.hr> wrote:
>> On Tuesday 06 March 2012 10:53:18 Monthadar Al Jaberi wrote:
>>> On Tue, Mar 6, 2012 at 12:52 AM, Marko Zec <zec@fer.hr> wrote:
>>> > On Monday 05 March 2012 22:14:45 Monthadar Al Jaberi wrote:
>>> >> Hi,
>>> >>
>>> >> I am a very happy VIMAGE user. But lately I have been having problems
>>> >> using it, and its too complicated for me to dig in so I hope you can
>>> >> help me (and help Adrian too).
>>> >>
>>> >> I am using FreeBSD Current with a kernel config without wlan module
>>> >> and wireless devices attach kernel config.
>>> >>
>>> >> uname -a shows:
>>> >> FreeBSD acke 10.0-CURRENT FreeBSD 10.0-CURRENT #2: Mon Mar 5 20:02:38
>>> >> CET 2012 root@acke:/usr/obj/usr/src/sys/VNET_without_wlan amd64
>>> >>
>>> >> I run the following commands:
>>> >> cd /usr/sys/module/wlan
>>> >> make load
>>> >> cd /usr/sys/modules/wtap
>>> >> make load
>>> >>
>>> >> then:
>>> >> /usr/src/ools/tools/wtap/wtap/wtap c 0
>>> >> ifconfig wlan create wlandev wtap0 wlanmode mesh
>>> >> wlandebug -i wlan0 hwmp+mesh+output+input+inact
>>> >> ifconfig wlan0 meshid mymesh
>>> >> ifconfig wlan0 inet 192.168.2.1
>>> >>
>>> >> and freebsd panics with:
>>> >> Mon Mar 5 21:17:46 CET 2012
>>> >> Mar 5 21:59:23 acke login: ROOT LOGIN (root) ON ttyv0
>>> >> Using visibility wtap plugin...
>>> >> Loaded wtap wireless simulator
>>> >> wtap0: ieee80211_radiotap_attach: no tx channel, radiotap 0x0wtap0:
>>> >> ieee80211_radiotap_attach: no rx channel, radiotap 0x0wlan0: Ethernet
>>> >> address: 00:98:9a:98:96:97
>>> >> wlan0: ieee80211_start: ignore queue, in SCAN state
>>> >> wlan0: [00:98:9a:98:96:97] ieee80211_alloc_node: inact_reload 2
>>> >> Kernel page fault with the following non-sleepable locks held:
>>> >> exclusive sleep mutex wtap0_com_lock (wtap0_com_lock) r = 0
>>> >> (0xffffff8002395018) locked @
>>> >> /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1937
>>> >> KDB: stack backtrace:
>>> >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
>>> >> kdb_backtrace() at kdb_backtrace+0x37
>>> >> _witness_debugger() at _witness_debugger+0x2c
>>> >> witness_warn() at witness_warn+0x2c4
>>> >> trap() at trap+0x2fe
>>> >> calltrap() at calltrap+0x8
>>> >> --- trap 0xc, rip = 0xffffffff80885d0c, rsp = 0xffffff80003e9a00, rbp
>>> >> = 0xffffff80003e9a20 ---
>>> >> rt_dispatch() at rt_dispatch+0x2c
>>> >> rt_ieee80211msg() at rt_ieee80211msg+0x7f
>>> >> scan_task() at scan_task+0x4cd
>>> >> taskqueue_run_locked() at taskqueue_run_locked+0x93
>>> >> taskqueue_thread_loop() at taskqueue_thread_loop+0x3e
>>> >
>>> > It may be that scan_task() calls further down into the network stack
>>> > without setting curvnet first.
>>>
>>> I added CURVNET_SET(TD_TO_VNET(curthread))/CURVNET_RESTORE() in
>>> scan_task but it didnt help
>>
>> scan_task() is called from a taskqueue trampoline which doesn't have a valid
>> TD_TO_VNET(curthread) context, so what you attempted to do can't work. You
>> need to set curvnet context to the one to which the network interface (or a
>> packet) you're working with belongs to. Perhaps you could use
>>
>> (struct ieee80211_scan_state *) ss->ss_vap->iv_ifp->if_curvnet
>>
>> in scan_task() to set curvnet, but having no clue on how the 80211 code works,
>> I might be wrong...
>>
>> And maybe you could consider rebuilding your kernel with options VNET_DEBUG
>> turned on - that should more verbosely point to the problem at hand, while
>> not introducing too big a performance penalty at runtime.
>>
>> Good luck,
>>
>> Marko
--
Monthadar Al Jaberi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BsBSoJUmzmOJmN8PvjfPTUDnez7MCHU9GvYpLNqER94haxk=g>