From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 14:36:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05CCA106564A for ; Thu, 23 Jul 2009 14:36:06 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 71BDE8FC20 for ; Thu, 23 Jul 2009 14:36:05 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 4FBE1EB4DD5; Thu, 23 Jul 2009 17:36:04 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 427A94C800E; Thu, 23 Jul 2009 17:36:04 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6VqLBkQPeBJ; Thu, 23 Jul 2009 17:36:04 +0300 (EEST) Received: from kobe.laptop (adsl129-11.kln.forthnet.gr [77.49.248.11]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 0E1D94C800D; Thu, 23 Jul 2009 17:36:04 +0300 (EEST) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n6NEa2I1044714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2009 17:36:03 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n6NEa1Ia044713; Thu, 23 Jul 2009 17:36:01 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Sam Leffler References: <87eis8g3b9.fsf@kobe.laptop> <4A67AF05.7060504@errno.com> Date: Thu, 23 Jul 2009 17:36:01 +0300 In-Reply-To: <4A67AF05.7060504@errno.com> (Sam Leffler's message of "Wed, 22 Jul 2009 17:29:57 -0700") Message-ID: <87hbx3zctq.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: lagg0 and tcpdump problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 14:36:06 -0000 On Wed, 22 Jul 2009 17:29:57 -0700, Sam Leffler wrote: > Giorgos Keramidas wrote: >> When I run tcpdump on lagg0 (with em0 and iwn0 as laggports), tcpdump >> seems to work fine, but typing ^C kills the wireless interface too. > > This is a known issue; bpf is holding a mutex over calls to the driver > that may block (in this case the taskqueue_drain calls in > net80211). It's unlikely to be resolved for 8.0 (too risky). Ok, it's good to know it is a known issue :) >> Then typing ^C stops tcpdump but the log shows: >> >> Jul 22 17:59:29 kobe kernel: wlan0: promiscuous mode disabled >> Jul 22 17:59:29 kobe kernel: em0: promiscuous mode disabled >> Jul 22 17:59:29 kobe kernel: iwn0: error, INTR=82000000 STATUS=0x40010000 >> Jul 22 17:59:29 kobe kernel: lagg0: promiscuous mode disabled >> Jul 22 17:59:30 kobe kernel: iwn0: iwn_transfer_firmware: timeout waiting for first alive notice, error 35 >> Jul 22 17:59:30 kobe kernel: iwn0: iwn_init_locked: could not load firmware, error 35 >> Jul 22 17:59:30 kobe kernel: wlan0: link state changed to DOWN >> Jul 22 17:59:30 kobe kernel: lagg0: link state changed to DOWN >> >> At this point wlan0 is without carrier, and stays that way until I >> unplumb wlan0 and lagg0 and re-create them. > Sounds like iwn isn't reacting well to the calls coming in from > lagg. wlandebug state should provide some insight. I've used > lagg+iwn+em on a t61p with no obvious issues but never tried to run > tcpdump on the lagg port. It's a Lenovo Thinkpad X61s I'm using for this, so I'll gather some wlandebug output and post more details. I think it's probably a problem with iwn because the other interface (em0) seems to be handling tcpdump runs better.