From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 22:01:14 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 47790D2E; Sun, 10 Nov 2013 22:01:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E66F224FD; Sun, 10 Nov 2013 22:01:13 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id w4so3572219qcr.12 for ; Sun, 10 Nov 2013 14:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gntL3o/ILZBzpBGtQ2V+eL+z9ULKnvM1MxMnk20LT2o=; b=uQ2Gfy0DZ227y3yfUBmaiKHmA3gGT7/4KLZf5Phadklc7q2/GrAvsWhkEGHDHhyvC0 SiDJz0Bc+dSrGYZwpEOLcz22XNm9YNHPtLybT0q+e1+7n9ppS7mODRimuj8iqm3UbJ4l ZuZGsCEbBx9B9gA3nosS8lfdn4M8FZEtpbu8RXgTUuvXds6Ka8OIioqZEbrUv2oECvDm lkxVTgPx7Js2Kvww9TlqVt5js4RCDwh7V6qY2rgW4yAFOUVfUIs8TWs/3V8zHWXzecK1 8nuEuf8isygG/Duo20Dc/NjnOe08NgGHvjpR36ZF5u1FnatiqwhsvhuFBuNdQ23yi8I1 IxjQ== MIME-Version: 1.0 X-Received: by 10.49.19.101 with SMTP id d5mr42120437qee.78.1384120873030; Sun, 10 Nov 2013 14:01:13 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sun, 10 Nov 2013 14:01:12 -0800 (PST) Received: by 10.224.207.66 with HTTP; Sun, 10 Nov 2013 14:01:12 -0800 (PST) In-Reply-To: <20131110193421.GB1778@mole.fafoe.narf.at> References: <20131110121737.GA1834@mole.fafoe.narf.at> <20131110163340.GA1778@mole.fafoe.narf.at> <20131110193421.GB1778@mole.fafoe.narf.at> Date: Sun, 10 Nov 2013 14:01:12 -0800 X-Google-Sender-Auth: 8B0swMie1ntvJ7oy_ivg8Ke7TTM Message-ID: Subject: Re: iwn(4) hangs after r257133 From: Adrian Chadd To: Stefan Farfeleder Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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 22:01:14 -0000 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 :) Thanks, Adrian Adrian On Nov 10, 2013 11:34 AM, "Stefan Farfeleder" wrote: > 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 >