From owner-freebsd-wireless@FreeBSD.ORG Sun Nov 10 06:20:16 2013 Return-Path: Delivered-To: freebsd-wireless@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 DAC50DE7; Sun, 10 Nov 2013 06:20:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8BED32896; Sun, 10 Nov 2013 06:20:15 +0000 (UTC) Received: by mail-qe0-f53.google.com with SMTP id cy11so3471541qeb.12 for ; Sat, 09 Nov 2013 22:20:14 -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=nOAzUpuZLwiOZqBwM0MBrWAXgbhZQhYT/4l7z5/dtvU=; b=GE54VnHwvZL4j3EhyZ2SPIcH1NG13UZkvztBmmjusEipRyCub5Yuo1o3/fIVGPCdCT o3vIpXIWcJz5W5zl1k8oB4oJ8WK3I+FMD0nSN8GvKiP9bKbKiL25y9qtkcxZ+GmlT3bo Ev4e+bCIyHlI5Jb1VOEM3sszallJbcB6aSd5FOnX/tYDye8gLI+L8SBNrUazEdvw3G0x +A16OkQglAqxqr90cDPTtbwbFby2jUUVJOlQZGvng6uiIvaMfNb+Lv5GYkAeYfQD9ihK NLDVaMMP0tFbuLDowbJkxIPUfkI7NEYf7cfS1WBeNXnd7+7f1lf1wRQgr7EGPpFdF36L uGZA== MIME-Version: 1.0 X-Received: by 10.49.19.101 with SMTP id d5mr36206753qee.78.1384064414800; Sat, 09 Nov 2013 22:20:14 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 22:20:14 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 22:20:14 -0800 X-Google-Sender-Auth: 8_TWKL1JMD7jG1w5jlopM0PSCMk Message-ID: Subject: Re: iwn(4) hangs after r257133 From: Adrian Chadd To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , FreeBSD Current X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 06:20:16 -0000 Oh, and you need to print out the tx->rate field using "0x%04x", rather than %d. The completion value is in hex. -adrian On 9 November 2013 22:18, Adrian Chadd wrote: > Sure, flip on 'wlandebug +rate' (assuming you compiled with IEEE80211_DEBUG) > > > -a > > On 9 November 2013 21:08, Brandon Gooch wrote: >> 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