From owner-freebsd-wireless@FreeBSD.ORG Mon Jan 2 06:20:13 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 446291065673 for ; Mon, 2 Jan 2012 06:20:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 330598FC13 for ; Mon, 2 Jan 2012 06:20:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q026KCJI005015 for ; Mon, 2 Jan 2012 06:20:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q026KCxU005014; Mon, 2 Jan 2012 06:20:12 GMT (envelope-from gnats) Date: Mon, 2 Jan 2012 06:20:12 GMT Message-Id: <201201020620.q026KCxU005014@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: Adrian Chadd Cc: Subject: Re: kern/163759: [at] ath(4) "stops working" in hostap mode X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Chadd 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: Mon, 02 Jan 2012 06:20:13 -0000 The following reply was made to PR kern/163759; it has been noted by GNATS. From: Adrian Chadd To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/163759: [at] ath(4) "stops working" in hostap mode Date: Sun, 1 Jan 2012 22:16:21 -0800 A little more digging has shown at least one source of these: software retries are sneaking onto the list. Ie: * force 11n aggregation up - do a whole bunch of traffic; * enabled debugging - sysctl dev.ath.1.debug=0x7c002000 - that's the SW TX handling bits and the TX_PROC debugging; * ping -i 0.3 in one screen * scan in the other (ifconfig wlan1 scan) * notice the tid_drain things being logged. What I've seen: * frame is queued via ath_start() or ath_raw_xmit() * .. it makes it out to the hardware * ath_tx_processq() is called in the flush routine, with dosched=0 * .. and it requires a retry, for reasons I haven't yet figured out. Since aggregation is up, the frame is retried in software. * .. so the frame is replaced on the software queue, but sched isn't called for it, so it sits on the software queue. * .. then drain is called, with a software-queued frame in the queue. So now, what should I do here? Hum. adrian