From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 19:34:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E651AC29; Sun, 10 Nov 2013 19:34:24 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep20.mx.upcmail.net (fep20.mx.upcmail.net [62.179.121.40]) by mx1.freebsd.org (Postfix) with ESMTP id 064272CA7; Sun, 10 Nov 2013 19:34:23 +0000 (UTC) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep20-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20131110193422.TWL1918.viefep20-int.chello.at@edge03.upcmail.net>; Sun, 10 Nov 2013 20:34:22 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge03.upcmail.net with edge id nvaN1m00J2xdvHc03vaNES; Sun, 10 Nov 2013 20:34:22 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id F1FC86D47B; Sun, 10 Nov 2013 20:34:21 +0100 (CET) Date: Sun, 10 Nov 2013 20:34:21 +0100 From: Stefan Farfeleder To: Adrian Chadd Subject: Re: iwn(4) hangs after r257133 Message-ID: <20131110193421.GB1778@mole.fafoe.narf.at> References: <20131110121737.GA1834@mole.fafoe.narf.at> <20131110163340.GA1778@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Brandon Gooch , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 10 Nov 2013 19:34:25 -0000 On Sun, Nov 10, 2013 at 10:48:48AM -0800, Adrian Chadd wrote: > Right near the end there you have 'status 83' which means 'transmit > failed, long retry hit' (the status codes are in if_iwnreg.h > somewhere.) The retry count hit 16, which is the max set for the > frame. > > rate=80 (hex) is MCS0. So, you're seeing retransmits and failures at > MCS0, which is a bad sign. > > But, notice how AMRR increased it to MCS2 at a couple stages, and that > _always_ fails. But AMRR waits for 10 frame transmits before it > adjusts the rate up or down. > > So yes, we do need to enable MRR again on iwn for things to behave > better. There are other issues when you start doing larger amounts of > traffic but I'll cover those later.what? > > If someone wants to take a crack at correctly implementing the link > quality table stuff again then please let me know. As I said before, > the link quality table setup code is mostly sane. The problem is > actually correctly setting 'linkq' to start at the selected rate, as > linkq is an index into that table, not the initial rate. Hi, after some trial and error I found out that disabling AMPDU makes my iwn0 usable again. Now I actually see the rate as reported by `list sta' going up and down (mostly between 54M and 121M). Before it was always fixed at 135M. Could this be related? Stefan