From owner-freebsd-wireless@FreeBSD.ORG Sun Jan 13 20:31:57 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ADDF4DD4 for ; Sun, 13 Jan 2013 20:31:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6FBA1F for ; Sun, 13 Jan 2013 20:31:56 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id z53so1738801wey.20 for ; Sun, 13 Jan 2013 12:31:50 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ynT7LNwlBFnj0sDI5ULnVaKiJk2gMdZZVF3KvQtfqSY=; b=Rh5eSc6QQhxGZn7JPVjZcwDd7mJ7Yu/D2H+TJYZJ9J+o7yhAp9Xf3lFu8JzaDEwzl8 rIumSYbcNY65yQKzaF3Pa4c2dFmgsn0ZaCMFaha+RHJCqbM1nW9e9E17ZdDzE3qrDtQI 0jlZFeB0OTs2omrWEqCFJTPCzlqIyTLJBoxNAw9OLN7N8W3kjnrHQV4w7LXxBchW0BCR FpltVk3gLiqIVayAi/2GPvWWfMWqutMSywBMZCLZcumkRcGXWkPIHAs8RdRA24rNFrKO Rc8FOXzmUiOpboTRwk4FX5f53u4ptsxkffhb40XH1JkMzHfWMQNIxBW1wdOfwnfqOXIf lCYg== MIME-Version: 1.0 Received: by 10.194.179.34 with SMTP id dd2mr131681333wjc.1.1358109110591; Sun, 13 Jan 2013 12:31:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sun, 13 Jan 2013 12:31:50 -0800 (PST) In-Reply-To: References: Date: Sun, 13 Jan 2013 12:31:50 -0800 X-Google-Sender-Auth: PVqsdEsmrXYpmq_M-uccW1rIFRg Message-ID: Subject: Re: freebsd-head and spectral scan From: Adrian Chadd To: Sven Hazejager Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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, 13 Jan 2013 20:31:57 -0000 Hi, The reason I haven't (yet) written any particular directions up on this is because I'm still trying to come up with relevant workarounds for spectral scan on the AR9280, when it's active with traffic. Since some of you will likely enable it with traffic and then discover that things hang (and frequently), I'd like to make sure the general case recoverable. What I've discovered thus far: * In STA mode, the beacon timer programming doesn't happen after a watchdog reset. * In STA mode, a beacon miss event can be indicative of RX deafness, so the right thing to do there is a no-loss reset. A reset does fix the RX deafness hang issue, but it doesn't reprogram the beacon timers, so subsequent beacon miss interrupts don't occur. * If I overflow the RX queue, the recovery doesn't .. recover. This may be a failure mode that's very specific to "RX queue overflow with PHY errors" rather than "RX queue overflow with data." At this stage, the RX just totally hangs until a reset occurs. I've fixed #1 and #2, and #3 is an interesting side-case. Once #2 was fixed, #3 immediately results in missed beacons, which results in a reset. But if too many missed beacons occur due to deafness, the association session is reset. So what I may do is: * Add the code to -HEAD to correctly reprogram the beacon timer after a missed beacon -> hardware reset; * Always reset the hardware after a beacon miss, in case it's a hang that we haven't yet detected; * Add the spectral scan related signatures to the HAL, so the ath_bmiss_proc() code doesn't call ieee80211_beacon_miss() and thus disassociate things. I'll also see if a full reset rather than a warm reset fixes whatever the bad PHY hardware state is that's causing things to continuously get stuck. Once that's done, I'll release some updated instructions so people can tinker with it, along with "this can hang all kinds of things and decrease performance, be careful" warnings. I may even wrap the code up in a github project or something and make a port. Adrian