From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 05:08:28 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 BF9695E9; Sun, 10 Nov 2013 05:08:28 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B44D2642; Sun, 10 Nov 2013 05:08:28 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id y13so968839pdi.14 for ; Sat, 09 Nov 2013 21:08:28 -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; bh=a/QEp6YVg5k7svHJjmkqSC6hisv5Y0acsD+v7AocXnQ=; b=GBOhh/Ng/sg2urCPCo25t4pReDPWd24SXDJXfbXaOEhl6sfQm0gSilxhICakRxtKZP NV6UZlW2V8obNr4nIkdQDzzeiyZbGEjEOwC5Ocgu4A4T9dHiDtfQ7tIgWQ1JiS7972kE aExMT4A65wM+xhugdD6WKY6YQS45oZZ9ZVpKkO1u5naUQ5TJYUsMKSxQpF1zI5CURxZU uTS2aLikJ5cZBLo3UdFJDfQP1469ydoQklbao7WkY+aUXApoQtzWVpdC9tGXO+X/hpZu O2wrqo/YgchEEhUfd4nN8ZHvWo71etvl5dLkPkZumwC5rU0MR19bgHVYZWfDP7MUg6HK EMPw== MIME-Version: 1.0 X-Received: by 10.68.191.3 with SMTP id gu3mr18959pbc.142.1384060108188; Sat, 09 Nov 2013 21:08:28 -0800 (PST) Received: by 10.68.57.72 with HTTP; Sat, 9 Nov 2013 21:08:28 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 23:08:28 -0600 Message-ID: Subject: Re: iwn(4) hangs after r257133 From: Brandon Gooch To: Adrian Chadd Content-Type: multipart/mixed; boundary=e89a8ff1c37418c95804eacb9b8c X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" , 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 05:08:28 -0000 --e89a8ff1c37418c95804eacb9b8c Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 9, 2013 at 8:46 PM, Adrian Chadd wrote: > Hi! > > On 9 November 2013 18:29, Brandon Gooch wrote: >> Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link >> 5300 to hang after only a few moments of use. > > That's .. odd. Ok. > >> For now, I've just reverted only those aspects of r257133, enabling >> MRR and keeping the rate index lookup, which seems to do something on >> my hardware at least (I assume it's not the right thing based on >> Adrian's analysis, but it works never-the-less). >> >> Has anyone else hit this with Intel WiFi hardware? >> >> Also, what needs to be done to have MRR working properly? > > So, it could be a fall out of how utterly crap AMRR is at 11n rates. > > Please compile with IWN_DEBUG, then do this before you associate: > > sysctl dev.iwn.0.debug=0x1 > > (that's IWN_DEBUG_XMIT in sys/dev/iwn/if_iwn_debug.h) > > You can do the same on a kernel with and without the MRR stuff enabled. > > I'd like to see what the actual rate selection looks like and what the > final rate selection is. We may have to patch the kernel to print out > the contents of 'rate' and 'tx->rate' in iwn_tx_data() to get that. I've attached the log output, both with and without MRR. The output looks very much the same within iwn_tx_data(); in iwn5000_tx_done() things are clearly different. If I'm reading the rate conversion bits correctly, I see anywhere from 6 Mbps to 60 Mbps, with the the non-MRR module "getting stuck" -- I really don't know what has happened when it does this. Is there any further debugging output that would be helpful? -Brandon > The MRR stuff is a bit special. I don't know how the link table works > in great depth yet. I know it's broken for 11n; it's plainly using the > wrong indexes now. That's why I disabled it. It shouldn't take that > much work to get it in the tree again; it'll just be fiddly. The easy > bit is populating the table. The hard bit is knowing which index to > set linkq to when transmitting a frame. > > > > -adrian --e89a8ff1c37418c95804eacb9b8c--