From owner-freebsd-virtualization@FreeBSD.ORG Tue Mar 6 19:53:04 2012 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E81E1065672 for ; Tue, 6 Mar 2012 19:53:04 +0000 (UTC) (envelope-from zec@fer.hr) Received: from munja.zvne.fer.hr (munja.zvne.fer.hr [161.53.66.248]) by mx1.freebsd.org (Postfix) with ESMTP id 1D34E8FC1E for ; Tue, 6 Mar 2012 19:53:03 +0000 (UTC) Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 20:53:01 +0100 Received: from localhost ([161.53.19.8]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 20:53:01 +0100 From: Marko Zec To: freebsd-virtualization@freebsd.org Date: Tue, 6 Mar 2012 20:52:39 +0100 User-Agent: KMail/1.9.10 References: <201203061633.03446.zec@fer.hr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201203062052.39902.zec@fer.hr> X-OriginalArrivalTime: 06 Mar 2012 19:53:01.0847 (UTC) FILETIME=[BCF04A70:01CCFBD2] Cc: Adrian Chadd Subject: Re: VIMAGE + kldload wlan + kldload wtap panic X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 19:53:04 -0000 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= =20 (which is a synonim for curthread->td_vnet) must be set to a proper context= =20 when calling into networking code, and restored to previous value on=20 returned. CURVNET_SET() and CURVNET_RESTORE() are macros which should be=20 used to do this. As far as I know there are three ways for a function call to end up in the= =20 networking code: A) system calls (socket related, or syctls); B) servicing= =20 inbound packets; and C) timers / periodic tasks. Cases A) and B) should be mostly covered in generic socket handlers and in= =20 netisr dispatchers, except sysctls which need to access any state you may=20 have decided to virtualize - those should converted to use SYSCTL_VNET_*=20 macros. Cases which fall into category C) are the ones which probably require most= =20 attention and in certain cases may require certain amount of code=20 restructuring. Handlers which are dispatched via timers are not bound to a= ny=20 of the network stack instances, so in those you have to follow one of the t= wo=20 possible strategies: 1) iterate over all existing VNETs and do your timer-driven stuff once in e= ach=20 of those - in that case take a look at how VNET_LIST_RLOCK(),=20 VNET_ITERATOR_DECL() and VNET_FOREACH() family of macros are used elsewhere= ,=20 or 2) if the timer-driven event is bound to an object which is associated with= an=20 ifnet interface, you should explicitly set the curvnet context to match the= =20 one the ifnet is associated with, using CURVNET_SET(ifp->if_vnet), as I=20 pointed out earlier in this thread. Buiding a VNET_DEBUG kernel may help you a bit to find out the critical spo= ts=20 when things go wrong, but don't expect miracles... I think both Julian and Bjoern have already written pretty nice and extensi= ve=20 documents covering those topics, but I would't know the current status or=20 whereabouts of those... Hope this helps, Marko > Adrian > > On 6 March 2012 07:33, Marko Zec wrote: > > On Tuesday 06 March 2012 10:53:18 Monthadar Al Jaberi wrote: > >> On Tue, Mar 6, 2012 at 12:52 AM, Marko Zec 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 proble= ms > >> >> 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 =A0attach kernel config. > >> >> > >> >> uname -a shows: > >> >> FreeBSD acke 10.0-CURRENT FreeBSD 10.0-CURRENT #2: Mon Mar =A05 > >> >> 20:02:38 CET 2012 =A0 =A0 > >> >> root@acke:/usr/obj/usr/src/sys/VNET_without_wlan =A0amd64 > >> >> > >> >> 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 =A05 21:17:46 CET 2012 > >> >> Mar =A05 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: Ethern= et > >> >> 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 =3D 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 =3D 0xffffffff80885d0c, rsp =3D 0xffffff80003e9a0= 0, rbp > >> >> =3D 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. =A0You need to set curvnet context to the one to which the network > > interface (or a packet) you're working with belongs to. =A0Perhaps 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscribe@freebsd.org"