From owner-freebsd-virtualization@FreeBSD.ORG Tue Mar 6 19:49:39 2012 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8266106566B for ; Tue, 6 Mar 2012 19:49:39 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7C3E58FC08 for ; Tue, 6 Mar 2012 19:49:39 +0000 (UTC) Received: by yhgm50 with SMTP id m50so2838923yhg.13 for ; Tue, 06 Mar 2012 11:49:38 -0800 (PST) Received-SPF: pass (google.com: domain of monthadar@gmail.com designates 10.50.219.170 as permitted sender) client-ip=10.50.219.170; Authentication-Results: mr.google.com; spf=pass (google.com: domain of monthadar@gmail.com designates 10.50.219.170 as permitted sender) smtp.mail=monthadar@gmail.com; dkim=pass header.i=monthadar@gmail.com Received: from mr.google.com ([10.50.219.170]) by 10.50.219.170 with SMTP id pp10mr11638428igc.49.1331063378763 (num_hops = 1); Tue, 06 Mar 2012 11:49:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BF8nILAwke1jR0gDbr+PtkD7IY9Db5yQcua9vTVGbek=; b=N1V5SnqeweAuRVdtcElG8+CBjUWXVK+UMrFwDlhUxVlsXZ8k7PPseRlv0AKd0d5QXv u79O0DTSsgPmOkLIBXffKhmw8ftzxiVhMQMHyHYWih/o4YnqFOAuwT/ydCR18jzUVoWY N1gKJ4YTc1iU3KBTO9vjSDGupHa0vVyEVIX5RM3GMuqr7ZRJG6L5bxveDG73pqE2C6XK t16x+pvW7TYTI3ctqZErfxBRDW63B5OfbycA0n0EEoqv8JDrNG5D5m6xHyYrjiPCJS+v Zt8an95P1YgcS4rrvxrEHSG05Z+90l8lfUnOqiMw5L/dwpY1e0tc6XMnUSF3f92zk0sj tmXQ== MIME-Version: 1.0 Received: by 10.50.219.170 with SMTP id pp10mr9699251igc.49.1331063378667; Tue, 06 Mar 2012 11:49:38 -0800 (PST) Received: by 10.50.236.67 with HTTP; Tue, 6 Mar 2012 11:49:38 -0800 (PST) In-Reply-To: References: <201203060052.28603.zec@fer.hr> <201203061633.03446.zec@fer.hr> Date: Tue, 6 Mar 2012 20:49:38 +0100 Message-ID: From: Monthadar Al Jaberi To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Marko Zec , freebsd-virtualization@freebsd.org 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:49:39 -0000 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 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 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 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