VIMAGE + kldload wlan + kldload wtap panic

Tue Mar 6 19:53:04 UTC 2012

On Tuesday 06 March 2012 19:01:11 Adrian Chadd wrote:
> Hi,
>
> What do we need to do to get VNET working in net80211 and the network
> drivers?

In principle one shouldn't have to touch anything in the network drivers.

In order for networking code to properly resolve virtualized state, curvnet 
(which is a synonim for curthread->td_vnet) must be set to a proper context 
when calling into networking code, and restored to previous value on 
returned.  CURVNET_SET() and CURVNET_RESTORE() are macros which should be 
used to do this.

As far as I know there are three ways for a function call to end up in the 
networking code: A) system calls (socket related, or syctls); B) servicing 
inbound packets; and C) timers / periodic tasks.

Cases A) and B) should be mostly covered in generic socket handlers and in 
netisr dispatchers, except sysctls which need to access any state you may 
have decided to virtualize - those should converted to use SYSCTL_VNET_* 
macros.

Cases which fall into category C) are the ones which probably require most 
attention and in certain cases may require certain amount of code 
restructuring.  Handlers which are dispatched via timers are not bound to any 
of the network stack instances, so in those you have to follow one of the two 
possible strategies:

1) iterate over all existing VNETs and do your timer-driven stuff once in each 
of those - in that case take a look at how VNET_LIST_RLOCK(), 
VNET_ITERATOR_DECL() and VNET_FOREACH() family of macros are used elsewhere, 
or

2) if the timer-driven event is bound to an object which is associated with an 
ifnet interface, you should explicitly set the curvnet context to match the 
one the ifnet is associated with, using CURVNET_SET(ifp->if_vnet), as I 
pointed out earlier in this thread.

Buiding a VNET_DEBUG kernel may help you a bit to find out the critical spots 
when things go wrong, but don't expect miracles...

I think both Julian and Bjoern have already written pretty nice and extensive 
documents covering those topics, but I would't know the current status or 
whereabouts of those...

Hope this helps,

Marko

> Adrian
>
> On 6 March 2012 07:33, Marko Zec <zec at 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 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
>
> _______________________________________________
> freebsd-virtualization at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to
> "freebsd-virtualization-unsubscribe at freebsd.org"