Date: Sun, 17 Mar 2013 08:03:40 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Kamil Szczesny <k.s.mail@gmx.net> Cc: freebsd-wireless@freebsd.org Subject: Re: ath0: device timeout on 9.1-RELEASE Message-ID: <CAJ-VmonBHK8=6gUHCVj7fsp1U5YS=COG80oXLTfVMN8TJL7YNQ@mail.gmail.com> In-Reply-To: <514584A5.6090601@gmx.net> References: <51175C69.6050003@gmx.net> <511E910D.1080901@gmx.net> <CAJ-Vmon9FskQtUdZ_nnTer6n7cGznqWQ6c4MZTm4DqT9cNTTng@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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, Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonBHK8=6gUHCVj7fsp1U5YS=COG80oXLTfVMN8TJL7YNQ>