From owner-freebsd-wireless@FreeBSD.ORG Fri Jun 15 09:06:58 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91A0B106564A for ; Fri, 15 Jun 2012 09:06:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 62D7C8FC16 for ; Fri, 15 Jun 2012 09:06:58 +0000 (UTC) Received: by dadv36 with SMTP id v36so3958422dad.13 for ; Fri, 15 Jun 2012 02:06:58 -0700 (PDT) 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 :content-transfer-encoding; bh=wpzyu9yT3ElTezQYzNkHlfA5YXqH1zpvkQy0CLil6Jw=; b=cX8I1cVNEkxScyACT2PlHHgefs6Qs/afrIH8zUscdPFd38UlPe4ogzIbNRoIH0fWa+ ze5LX60VqdU3Yu4FH+TL1j+yfDfdDBYIx927SCvu82UcZiQlC1OWdPSEBOB+DqJLwnAW 6xjRcBPXj4tJMZRm2A/B44jUcnseuqQRgx4N4VV2amMRUB79VBFpzLhWJ/yiHE+Sm+8g R7xP/+GxgYT0qaUg9xWY1klPcXwWNCyl3Ra2XPiecZrGItUq95RzyE7k/Ab223geERXM D3JWcI+MFiPX3j1xwb6yoG+K1+HSPjAvW3nIjhYRSHr7kW5Eoe0atH4XoZdoEPGvdZbP xQaA== MIME-Version: 1.0 Received: by 10.68.226.226 with SMTP id rv2mr17954888pbc.101.1339751218067; Fri, 15 Jun 2012 02:06:58 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.91.18 with HTTP; Fri, 15 Jun 2012 02:06:58 -0700 (PDT) In-Reply-To: <201206120837.20027.jhugo@meraka.csir.co.za> References: <201206120837.20027.jhugo@meraka.csir.co.za> Date: Fri, 15 Jun 2012 02:06:58 -0700 X-Google-Sender-Auth: CpFGs3HOZsIOcPMdRdaYkbd5HkU Message-ID: From: Adrian Chadd To: Johann Hugo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org Subject: Re: [heads up] please test -HEAD ath(4) 802.11n! 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: Fri, 15 Jun 2012 09:06:58 -0000 On 11 June 2012 23:37, Johann Hugo wrote: > Are you interested in -HEAD ath(4) 802.11n on -9 ? Sure, if you turn on debugging! > The 11n adapter was in AP mode. It worked for a while giving a lot of > ath_tx_normal_setup messages and then it stopped. > > =A0After an ifconfig down/up it worked again, with no more =A0ath_tx_norm= al_setup > messges, but I only get half the speed. Did it log anything interesting in dmesg when you brought it down/up? If the traffic stalled, it should have logged some basic information about the state of the software queue. > ifconfig wlan0 down > ath0: ath_tx_tid_drain: node 0xc27e7000: bf=3D0xc21cff48: addbaw=3D0, dob= aw=3D1, > seqno=3D496, retry=3D0 > ath0: ath_tx_tid_drain: node 0xc27e7000: bf=3D0xc21cff48: tid txq_depth= =3D54 > hwq_depth=3D0, bar_wait=3D1 Ah, here it is. > ath0: ath_tx_tid_drain: node 0xc27e7000: tid 0: txq_depth=3D1, txq_aggr_d= epth=3D0, > sched=3D0, paused=3D1, hwq_depth=3D0, incomp=3D0, baw_head=3D17, baw_tail= =3D17 > txa_start=3D496, ni_txseqs=3D550 > FRDS 00:1b:21:13:31:b6->14:7d:c5:65:4b:88(00:80:48:66:54:b4) data QoS [TI= D 0] > 0M > =A08802 0000 147d c565 4b88 0080 4866 54b4 001b 2113 31b6 001f 0000 0000 = aaaa > 0300 0000 0800 > ath0: ath_tx_default_comp: bf 0xc21cff48: seqno 496: dobaw should've been > cleared! So, hm. There was one frame in the TID queue, the queue was paused, the hardware queue had one frame in it (but not from that TID, maybe it was the BAR frame going out) and bar_wait is 1. So I bet something weird has happened with BAR TX. What happens here is: * TX aggregation fails and the TX sender needs to inform the receiver that the Block ack window (BAW) needs to be moved along artificially as there's a "hole" where the TX has failed; * .. and this happens from too many retries; * So it pauses the node TID queue and waits for the hardware frames to finish transmitting; * once that occurs, it knows where the "hole" will be and sends a BAR frame to the receiver to say what sequence number the subsequent aggregate frames will begin from; * the receiver ACKs the frame normally; * the sender then restarts the traffic by unpausing the TID and marking the BAR flag as done. It seems your BAR TX "stuck". I've just modified the TX path a little to have (a) a small pool of TX buffers just for management traffic, and (b) to limit how many buffers are allocated when sending traffic so there's a small headroom available for cloning buffers when retransmitting them. I have to work on (c) soon - to limit how many TX buffers a given node / TID can consume so you don't have one node monopolising things. So please try the latest -HEAD and see if the problem persists. It _should_ fix itself after 30 seconds (when the BAR TX times out and the session is dropped back to non-aggregate.) Thanks! Adrian