From owner-freebsd-virtualization@FreeBSD.ORG Tue Mar 6 20:13:01 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 46AA81065677 for ; Tue, 6 Mar 2012 20:13:01 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 043F98FC17 for ; Tue, 6 Mar 2012 20:13:00 +0000 (UTC) Received: by iahk25 with SMTP id k25so10208595iah.13 for ; Tue, 06 Mar 2012 12:13:00 -0800 (PST) Received-SPF: pass (google.com: domain of monthadar@gmail.com designates 10.50.181.199 as permitted sender) client-ip=10.50.181.199; Authentication-Results: mr.google.com; spf=pass (google.com: domain of monthadar@gmail.com designates 10.50.181.199 as permitted sender) smtp.mail=monthadar@gmail.com; dkim=pass header.i=monthadar@gmail.com Received: from mr.google.com ([10.50.181.199]) by 10.50.181.199 with SMTP id dy7mr11502266igc.57.1331064780533 (num_hops = 1); Tue, 06 Mar 2012 12:13:00 -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:content-transfer-encoding; bh=eN46EOKHrPstX4UWebTxaiiBWHOY4wFV80VJbmxmYc4=; b=y9BVJKJMkvd8UZYRdLfBYbdbUpqScfUU+zXDLFniIf+j0cQaPFGtN7HsYzSiqyZYTd mErv2MCnbaQlyY8fE0H+52dUds1/zt47cstxAJfnUk0iW8qpIFXQi/gp2w19sj/ZvvPd iy3kAYvwqUN1/IhYkWONUVwe6C/zdRzwC4tjq4j+9ZcKgHPXN/JAbQGhbVLJbansM6Iw vmrbnl1jFNbvV4hFxKqLlEU0uReqT5VMQJxv6A63m4wuTBJz1kOShj+y7iGuuWuY2+H3 XL/kzWR0lw3htcLUvxy6MaJGeTw+tI5hNwHq3ki5P1xBiozI3AUR5H1lpuq3CMyJgAap wFVQ== MIME-Version: 1.0 Received: by 10.50.181.199 with SMTP id dy7mr9586364igc.57.1331064780426; Tue, 06 Mar 2012 12:13:00 -0800 (PST) Received: by 10.50.236.67 with HTTP; Tue, 6 Mar 2012 12:13:00 -0800 (PST) In-Reply-To: References: <201203062059.31736.zec@fer.hr> Date: Tue, 6 Mar 2012 21:13:00 +0100 Message-ID: From: Monthadar Al Jaberi To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 20:13:01 -0000 I am confused so whats the difference between having wlan in kernel config or not? Cuase that seems the reason why we panic... linker problems? On Tue, Mar 6, 2012 at 9:06 PM, Adrian Chadd wrote= : > Hi, > > The trouble here is that net80211 has quite a few other contexts that > things are called from: > > * driver taskqueue; > * net80211 taskqueue; > * driver callouts; > * net80211 callouts; > * ioctls via net80211. > > That's in parallel with frame tx/rx and device ioctls. > > I don't personally have the time to go through net80211 and driver(s) > at the moment to figure out what's going on. Since ath(4) does a bunch > of frame processing in taskqueue context (and I'm trying to eliminate > frame processing in _callout_ context, ew..) things can potentially > get a bit hairy. > > > Adrian > > > On 6 March 2012 11:59, Marko Zec wrote: >> On Tuesday 06 March 2012 20:49:38 Monthadar Al Jaberi wrote: >>> I added VNET_DEBUG and noticed this warning (original scan_task code): >>> >>> CURVNET_SET() recursion in sosend() line 1350, prev in kern_kldload() >>> =A0 =A0 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 >> >> You can safely ignore those. =A0Recursing on curvnet is harmless, but in= certain >> cases can't be avoided. >> >> When injecting new CURVNET_SET() / CURVNET_RESTORE() points in the exist= ing >> code, those warnings are here to help us becoming aware that we are sett= ing >> curvnet in a function which was invoked with an already valid curvnet >> context. >> >> Marko --=20 Monthadar Al Jaberi