From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 24 13:12: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 5E70347E for ; Sun, 24 Mar 2013 13:12:22 +0000 (UTC) (envelope-from k.s.mail@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by mx1.freebsd.org (Postfix) with ESMTP id 0A8B6A2E for ; Sun, 24 Mar 2013 13:12:21 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MbNJC-1U0zPk3Zie-00IlXz for ; Sun, 24 Mar 2013 14:12:20 +0100 Received: (qmail invoked by alias); 24 Mar 2013 13:12:20 -0000 Received: from pD9FB8E24.dip.t-dialin.net (EHLO [192.168.2.104]) [217.251.142.36] by mail.gmx.net (mp027) with SMTP; 24 Mar 2013 14:12:20 +0100 X-Authenticated: #32709443 X-Provags-ID: V01U2FsdGVkX1+YT6III06YC6M/e6LAMHb0k6/Msd98gLfmXgrsoL o9UKp5rZayrl0B Message-ID: <514EFBB2.3080209@gmx.net> Date: Sun, 24 Mar 2013 14:12:18 +0100 From: Kamil Szczesny User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: ath0: device timeout on 9.1-RELEASE References: <51175C69.6050003@gmx.net> <511E9446.4070708@gmx.net> <511E9615.3020007@gmx.net> <512376AB.10003@gmx.net> <5123A714.6050105@gmx.net> <5130AF59.5080803@gmx.net> <5131197F.5050700@gmx.net> <5140E8D9.9020609@gmx.net> <5144253B.9050409@gmx.net> <514584A5.6090601@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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, 24 Mar 2013 13:12:22 -0000 Am 17.03.13 16:03, schrieb Adrian Chadd: > Hi! > > So this is exactly what I needed! > > On 17 March 2013 01:53, Kamil Szczesny wrote: >> Hi, >> >> it is an 11n NIC, but 11n mode was not working on 8.x-RELEASE either. What I >> am hoping for is that with 9.x-RELEASE 11n will work. We'll see. >> >> It's this one here: > AR5418! (PCIe AR5416.) > >> ath0@pci0:2:0:0: class=0x028000 card=0x3a701186 chip=0x0024168c >> rev=0x01 hdr=0x00 >> Something different, is it possible that with timer=i8254 the systemclock is >> getting faster out of sync? >> >> With 'sysctl dev.ath.0.debug=0x23' the debugging output is more verbose. >> Here we go: > [snip] > >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_dmasetup: m 0xfffffe0014902b00 >> len 42 >> Mar 17 09:39:26 gomorrha kernel: NODS >> 1c:7e:e5:10:61:16->ff:ff:ff:ff:ff:ff(ff:ff:ff:ff:ff:ff) probe_req 1M >> Mar 17 09:39:26 gomorrha kernel: 4000 0000 ffff ffff ffff 1c7e e510 6116 >> ffff ffff ffff 0000 0000 0108 8284 8b96 0c12 1824 3204 3048 606c >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_chaindesclist: 0: 00000000 >> 144f9ee8 213f002e 0120002a 00010000 0000001b >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_handoff: TXDP[1] = 0x5549600 >> (0xffffff810b33b600) depth 1 > So here you've queued a frame. > >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_chan_set: 6 (2437 MHz, flags >> 0x480) >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_draintxq: tx queue [9] 0, link 0 >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_stopdma: tx queue [0] 0, link >> 0 >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_stopdma: tx queue [1] >> 0x5549600, link 0xffffff810b33b600 >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_stopdma: tx queue [2] 0, link >> 0 >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_stopdma: tx queue [3] 0, link >> 0 >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_stopdma: tx queue [8] 0, link >> 0 >> Mar 17 09:39:26 gomorrha kernel: Q1[ 0] (DS.V:0xffffff810b33b600 >> DS.P:0x5549600) L:00000000 D:144f9ee8 F:0413 ! >> Mar 17 09:39:26 gomorrha kernel: 213f002e 0120002a 00010000 0000001b >> 0000023a 00000000 >> Mar 17 09:39:26 gomorrha kernel: 00000000 00000004 00000000 3f000000 >> 3f000000 3f000000 00808080 00000002 > The last DWORD in this line is Tx.Status[1] (ds_status1 in ar5416desc.h.) > >> Mar 17 09:39:26 gomorrha kernel: 00000000 00000000 00000000 80808080 >> 80808080 80808080 80808080 00000001 > The last DWORD in this line is Tx.Status[9] (ds_status9 in ar5416desc.h) > > .. and here, in ath_tx_stopdma(), the frame shows up as completed but > the error status is "excessive retries." > > Now - it could be because the NIC isn't sending back an interrupt and > it always shows up as excessive retries. It could be that the NIC is > trying to transmit it but then the channel change comes along and > cancels the frame transmit immediately, leading to the aborted frame > showing up like this. > > Are you able to update to -HEAD? Not only have I made some changes > with the AR5416 HAL and general TX handling, there's extra logging we > can enable to see fine grain timestamped descriptor information. > That'll tell us whether the hardware is trying to send the frame or > not. Thanks a lot for your effort and help! But unfortunately updating to HEAD is not an option for me, sorry at this point. I guess there is no way in using only the ath driver from 8.x or HEAD with 9.1? This very same nic was working at least with 8.x. regards, Kamil > Thanks, > > > > Adrian >