Date: Sun, 24 Mar 2013 14:12:18 +0100 From: Kamil Szczesny <k.s.mail@gmx.net> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-wireless@freebsd.org Subject: Re: ath0: device timeout on 9.1-RELEASE Message-ID: <514EFBB2.3080209@gmx.net> In-Reply-To: <CAJ-VmonBHK8=6gUHCVj7fsp1U5YS=COG80oXLTfVMN8TJL7YNQ@mail.gmail.com> References: <51175C69.6050003@gmx.net> <511E9446.4070708@gmx.net> <511E9615.3020007@gmx.net> <CAJ-VmokfSBqsOrGr7GRvyvjvA61mo9Dx5uTinPJyfs%2BuK4CoUg@mail.gmail.com> <512376AB.10003@gmx.net> <CAJ-Vmo=we%2Bx_8pohC=BVu0euEdg7VnHBABLNcJwpk6rNhfye_g@mail.gmail.com> <CAJ-Vmo=%2Bm=nLSBWYM0kdSWqP7vsZAg%2B52z0mtWvMmBZXPQvAtQ@mail.gmail.com> <5123A714.6050105@gmx.net> <CAJ-Vmo=LZZcLo-mjBXzrkNYnqzTr-NpBFgeQBUBCk8D4X2w3JA@mail.gmail.com> <CAJ-Vmo=SRZMt5AsEzvomTWKLSyztP0u9e_TA6wiy8g6sviuh6w@mail.gmail.com> <5130AF59.5080803@gmx.net> <CAJ-Vmo=gmOxcOWB_hW_11RCOvhM8=6CFSn4zGmdV_hsKOcmY_g@mail.gmail.com> <5131197F.5050700@gmx.net> <CAJ-VmokjACsDoEx5BV8BoSWtD5NbQ3WA6ABsyNvQOW7V_zOHZQ@mail.gmail.com> <5140E8D9.9020609@gmx.net> <CAJ-VmomhvU7xXV-0YnFs-mFJ2WEeRidBw243CRRDTSbmXcYr-w@mail.gmail.com> <5144253B.9050409@gmx.net> <CAJ-Vmo=XoMCfNLODobMZuZ_AoGDd_Vv=HjpWsG52x8vLvyFbJg@mail.gmail.com> <514584A5.6090601@gmx.net> <CAJ-VmonBHK8=6gUHCVj7fsp1U5YS=COG80oXLTfVMN8TJL7YNQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <k.s.mail@gmx.net> 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?514EFBB2.3080209>