From owner-freebsd-wireless@FreeBSD.ORG Sun Apr 28 19:41:39 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 4ABBEB90; Sun, 28 Apr 2013 19:41:39 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0611812A5; Sun, 28 Apr 2013 19:41:38 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:c1ca:3dbc:5137:8c40]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id B4EB04AC57; Sun, 28 Apr 2013 23:41:33 +0400 (MSK) Date: Sun, 28 Apr 2013 23:41:33 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <979648529.20130428234133@serebryakov.spb.ru> To: Adrian Chadd Subject: Re: New hardware, old problem: stuck beacon when here is WiFi traffic In-Reply-To: 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.sp b.ru> <1467048277.20130428225006@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org 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:41:39 -0000 Hello, Adrian. You wrote 28 =E0=EF=F0=E5=EB=FF 2013 =E3., 23:38:20: AC> There's some race condition hack that Sam threw in that gets enabled AC> only if you compile things with TDMA support enabled. Would you mind AC> compiling in TDMA support (add options IEEE80211_SUPPORT_TDMA) to your AC> kernel config and rebuild? I'd like to see if that TX queue workaround AC> is effective at helping us out here. I'm building it right now. It is good, that only kernel rebuild is fast. AC> Does this happen with tcp iperf? or only udp iperf? First time it was with tcp (some time ago). I could check this too. --=20 // Black Lion AKA Lev Serebryakov