VIMAGE + kldload wlan + kldload wtap panic

[Marko Zec]

On Tuesday 06 March 2012 10:53:18 Monthadar Al Jaberi wrote:
> On Tue, Mar 6, 2012 at 12:52 AM, Marko Zec <zec at 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 at 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