From owner-freebsd-wireless@FreeBSD.ORG Wed Dec 21 21:12:46 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76325106564A for ; Wed, 21 Dec 2011 21:12:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2BA908FC16 for ; Wed, 21 Dec 2011 21:12:45 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so10616905vcb.13 for ; Wed, 21 Dec 2011 13:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=i/Rr8R60QhptC+T2Uq0tdY3XwYpICwe+Dc3zLFSGJFY=; b=ilFajnrrBTHddCYMby7OS0tuoRikgglfmPMgrKJWD1ANOrPTeB/YLIIi7OPianU/Dj Fbem/Oi5//HPUt7dLm01iUAUCEqoBgQdoJJEXL8/A9cMQeaVYTDliQ2TndUmCPAMTJmo XZBp1/YEdOOYnqJStU6mAzhim2SbGyd4OfinM= MIME-Version: 1.0 Received: by 10.52.94.75 with SMTP id da11mr4705398vdb.111.1324501965391; Wed, 21 Dec 2011 13:12:45 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.158.104 with HTTP; Wed, 21 Dec 2011 13:12:45 -0800 (PST) In-Reply-To: References: <4EF23CD7.7090402@bettercom.de> Date: Wed, 21 Dec 2011 13:12:45 -0800 X-Google-Sender-Auth: X--Fxdn0Zg3wOKR4GAFTMMS4-hs Message-ID: From: Adrian Chadd To: Martin Lesser Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: stuck beacon with if_ath: old but unresolved issue X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 21 Dec 2011 21:12:46 -0000 So the background with this kind of issue is that "stuck beacon" can mean a lot of things. It first means "I can't transmit the beacon", which could be (and this isn't an exhaustive list): * due to DMA activity (eg, it can't DMA because the bus is busy); * due to incorrect programming (eg something I found w/ staggered beacons and the content-after-beacon window programming, this upset some of the later generation MACs); * due to busy air (ie the baseband thinks the air is constantly too busy to transmit); * due to incorrect radio programming (eg the ANI code changes the radio parameters in a way that makes things more sensitive to busy air); * due to incorrect antenna selection/programming/design - eg, the noise floor calibration occurs based on a non-attached antenna, but the busy air is received on the attached antenna, causing some very incorrect values to be programmed in. * completely busted hardware - eg, you may find your hardware has noise spurs in the 2.4ghz region. It's sometimes possible to program around these but quite often it isn't. (And who knows what the manufacturer put in their driver to work around this.) The trick is figuring out what is actually going on. The 0th step is to try -HEAD. :-) I fixed a bunch of subtle incorrect programming which hasn't necessarily been backported to -9. So please, try -HEAD out. The first step is to identify whether the bus is busy. Your bus isn't, so I bet it's not that. The next step is to see how busy the hardware thinks the air is. I unfortunately need to backport this work to -HEAD in order to make this easily doable. If it's a "busy air" problem, hopefully we can figure out whether it's just a case of twiddling the ANI parameters to deal with things a bit better. But it could be due to antenna stuff, or noise spurs, or incorrect radio programming. I don't know the pre-11n NICs at all and I haven't yet gone looking for the legacy chipset documentation. So please bear with me whilst I go through this transition into my new job (which is wireless, but not hacking on FreeBSD code during paid hours.) I do have plans to write some more debugging and diagnostic tools but I'm just swamped at the moment. Thanks, Adrian