From owner-freebsd-current@FreeBSD.ORG Mon Nov 11 08:19:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7E966D58; Mon, 11 Nov 2013 08:19:07 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep23.mx.upcmail.net (fep23.mx.upcmail.net [62.179.121.43]) by mx1.freebsd.org (Postfix) with ESMTP id A98702292; Mon, 11 Nov 2013 08:19:06 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep23-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20131111081858.JGC13029.viefep23-int.chello.at@edge04.upcmail.net>; Mon, 11 Nov 2013 09:18:58 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge04.upcmail.net with edge id o8Jy1m01G2xdvHc038Jyuj; Mon, 11 Nov 2013 09:18:58 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 3C8176D44C; Mon, 11 Nov 2013 09:18:58 +0100 (CET) Date: Mon, 11 Nov 2013 09:18:58 +0100 From: Stefan Farfeleder To: Adrian Chadd Subject: Re: iwn(4) hangs after r257133 Message-ID: <20131111081857.GA1809@mole.fafoe.narf.at> References: <20131110121737.GA1834@mole.fafoe.narf.at> <20131110163340.GA1778@mole.fafoe.narf.at> <20131110193421.GB1778@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: Mon, 11 Nov 2013 08:19:07 -0000 On Sun, Nov 10, 2013 at 02:01:12PM -0800, Adrian Chadd wrote: > Yes. So one of the.. unfortunately broken things in iwn is the ampdu tx > code doesn't do retransmits. So if amrr picks a rate that fails to transmit > everything, the driver doesn't retransmit them. It frees them. > > Now when amrr is enabled the hardware will retry at lower rates until > something succeeds. But it still doesn't retransmit things. I believe it > should be. > > So yes its more broken with Mrr disabled. But enabling mrr doesn't fix it. > It just makes it less broken. Someone needs to implement ampdu retransmit. > > The latest iwn code in head at least tells the rate selection code that a > total ampdu tx failure occured. This BTW is one of the hangs I fixed - if > you hit a point where you never successfully transmitted an ampdu at a rate > the rate would never be decreased. > > Now to be clear. I won't be in implementing ampdu retransmit. I'll maybe > fix last multi rate retry once the new hardware support is in. I would > really appreciate help here with these. Everyone with iwn hardware will > appreciate it :) In the mean time, wouldn't it make sense to disable ampdu tx in iwn then? Or to disallow the combination Mrr + ampdu? Stefan