From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 06:18:42 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 C76B1CC1; Sun, 10 Nov 2013 06:18:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 775132881; Sun, 10 Nov 2013 06:18:42 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id k18so3223526qcv.10 for ; Sat, 09 Nov 2013 22:18:41 -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=I2fy0r4ihOd9uO/QHPUiC8C5QGCdmPjxu2yPsj2Bzt4=; b=s9Tr0SwvdlHwGEoilPqRnmJee/R/wkvebBpBRErbx358sHQ1aRB5JVGu9byFuWTCjt qRe8EfeGEHe7d7OJvEw/cq3pThzFX2ziKivaM6KCuAOcs1UjoZ2v54Sv+8cGjzGB+pMC wNUGvOoRrQnc3Va8+C/Yb78NOEgBag7PlWFshptlsqC4pyOLqyklnvlxpgLGCvSsx6AI dRtw0FhW7hOA8aogAh9kg+mlo7Z1WpurSNba+DMiv3ncjQAoD/W1ywJvbGwIPekkHr1h THhwdqKxP3Egh0IdcnAev710KZOE7Fo/91uOYQS87XCZVAilp6EHSFa7ACvqnXWAr0D8 lMpw== MIME-Version: 1.0 X-Received: by 10.49.59.70 with SMTP id x6mr36083906qeq.17.1384064320964; Sat, 09 Nov 2013 22:18:40 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 22:18:40 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 22:18:40 -0800 X-Google-Sender-Auth: UlgghoWcP8q-e19zZ2xyCpWxk0Y 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-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 06:18:42 -0000 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