From owner-freebsd-wireless@FreeBSD.ORG Sun Apr 28 19:38:22 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 355549DC; Sun, 28 Apr 2013 19:38:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by mx1.freebsd.org (Postfix) with ESMTP id 9402A128C; Sun, 28 Apr 2013 19:38:21 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id k13so3210245wgh.7 for ; Sun, 28 Apr 2013 12:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Ekejyixzld1AS0T6d5W7esXg0aza1S5c3EsRHj/Coyk=; b=mqe3N2nXGihV2qBWGn/udojBz3k0MnR8LyYj1ml88H/tgguu/dVWUxOSJe4kdnVljP lD+ixYUYbwglhERLZDRcKt+PuN0vggJMk8EClgFfuA3sSBi9Vt85x1IRPSqOA2QZkMMd 86OO9y5boWvd0XUwBlNTENBkBK9XcXVb9X67Jjwn9ymrR0bJcEn/06mZ4MWijYDOGB/q G0XxNGuJV+tzu35cwLWAyeQ9l42zg5z04bXoJlOIc781rTeQEBhHZhUoAAiH9bU/KUBT UTtG7LfInc6WiClFhMsdqJm36sWUuQPLyoqB34IyVMvoxIjPEjBViHIpDFtIbjQZUQiL eefQ== MIME-Version: 1.0 X-Received: by 10.194.119.33 with SMTP id kr1mr11499468wjb.36.1367177900170; Sun, 28 Apr 2013 12:38:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Sun, 28 Apr 2013 12:38:20 -0700 (PDT) In-Reply-To: <1467048277.20130428225006@serebryakov.spb.ru> References: <2810538978.20130423164137@serebryakov.spb.ru> <1813905823.20130423184528@serebryakov.spb.ru> <184105677.20130424002002@serebryakov.spb.ru> <1936997795.20130424003555@serebryakov.spb.ru> <886711115.20130424004702@serebryakov.spb.ru> <6010292503.20130426001447@serebryakov.spb.ru> <99510815.20130426122508@serebryakov.spb.ru> <777510536.20130427123352@serebryakov.spb.ru> <1467048277.20130428225006@serebryakov.spb.ru> Date: Sun, 28 Apr 2013 12:38:20 -0700 X-Google-Sender-Auth: X8JGHuP_3zAlDmQi8mXWdncp-9g Message-ID: Subject: Re: New hardware, old problem: stuck beacon when here is WiFi traffic From: Adrian Chadd To: Lev Serebryakov 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, 28 Apr 2013 19:38:22 -0000 On 28 April 2013 11:50, Lev Serebryakov wrote: > 300M. Only 11-30M seen by client now, but no beacon stucks. > After AP hangs several forced beacon stucks + hostaptd restart > allow client to re-associate. Right. That's likely because 11n aggregation wasn't enabled. I don't know why. > Log with dev.ath.0.debug=0x900000020 attached ("sudo" messages are left as > "time marks"). Cool, thanks. It's odd. The descriptor list(s) look fine - ie, the descriptors aren't out of order or anything. (Ie, the descriptor and link pointers line up with the order that the ath_buf's are in the TXQ.) And the descriptors in your particular setup aren't chained into multi-descriptor lists, they're one descriptor per frame. There used to be bugs with my 11n TX code and which ath_buf to check the status of in a list of ath_bufs, but this last test is with no aggregation. So that's not a problem. The next step is seeing whether the hardware queue is actually just plain stuck, or whether it's idle. If it's idle, it may just be waiting for another call to ath_hal_txstart() or whatever the call is to re-trigger it. The only reason it would be idle like that though is if it hit the end of the descriptor list at about the same time we appended a frame to the list. However, every time we append a frame to the hardware queue, we also call ath_hal_txstart() to re-kick TX. There's some race condition hack that Sam threw in that gets enabled only if you compile things with TDMA support enabled. Would you mind compiling in TDMA support (add options IEEE80211_SUPPORT_TDMA) to your kernel config and rebuild? I'd like to see if that TX queue workaround is effective at helping us out here. Does this happen with tcp iperf? or only udp iperf? adrian