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.m...@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


_______________________________________________
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to