Category Archives: atheros

AR9160 11n performance – finally!

I've made some good progress with the AR9160 802.11n hostap mode in FreeBSD.

Firstly, the A-MPDU density setting needed tuning. "0" or "N/A" isn't appropriate for the AR9160 (and likely not appropriate for anything earlier than the AR9300/AR9400 series.) Once set to 8 microseconds, the number of A-MPDU retransmits dropped dramatically.

I found that there was some missing code to do with disabling RIFS (reduced inter-frame spacing) RX on the AR9160 which I committed to FreeBSD-HEAD. This has eliminated all of the baseband lockups I've been seeing, rare as they were now.

Then I found there were packets being dropped by if_arge on TX. It turns out the default TX/RX ring buffer size for if_arge was 128 packets - definitely not enough given the uncoupled interrupt/process driven forwarding engine in UNIX these days.

The background: since NIC drivers aren't doing their work in an interrupt or shared process context, they only do their work when their TX/RX tasks get scheduled. Since they don't have any way to signal each other to "back off" via flow control when the queues are getting filled, it's quite possible to have a very busy device (in this instance wlan0 RX'ing anything more than around 100mbit) queue enough packets to the devices' TX queue faster than the TX task can be scheduled to process packets.

Bumping if_arge's default TX/RX ring buffer size from 128 to 1024 did the trick - no more packet drops on TX.

Now I'm getting ~ 105mbit TCP RX in HT/40 5GHz hostap mode (since A-MPDU RX is implemented and working) and ~ 210mbit UDP RX before I begin to drop packets. Anything more than 210mbit starts resulting in the infamous "stuck beacon", but that could be for a variety of reasons. I don't think I'm saturating the PCI bus (read: the CPU scheduler does show about 30% idle clock cycles during a UDP RX test) so there's something else to be blamed.

Next is figuring out whether there's some scheduling issues with the device TX/RX tasks.

I find it quite creepy that I can get ~ 100mbit of 802.11n throughput to my macbook pro whilst lying in bed. But that's what 802.11n is for, right? :)

AR9160 11n performance – finally!

I've made some good progress with the AR9160 802.11n hostap mode in FreeBSD.Firstly, the A-MPDU density setting needed tuning. "0" or "N/A" isn't appropriate for the AR9160 (and likely not appropriate for anything earlier than the AR9300/AR9400 series.) Once set to 8 microseconds, the number of A-MPDU retransmits dropped dramatically.I found that there was some missing code to do with disabling RIFS (reduced inter-frame spacing) RX on the AR9160 which I committed to FreeBSD-HEAD. This has eliminated all of the baseband lockups I've been seeing, rare as they were now.Then I found there were packets being dropped by if_arge on TX. It turns out the default TX/RX ring buffer size for if_arge was 128 packets - definitely not enough given the uncoupled interrupt/process driven forwarding engine in UNIX these days.The background: since NIC drivers aren't doing their work in an interrupt or shared process context, they only do their work when their TX/RX tasks get scheduled. Since they don't have any way to signal each other to "back off" via flow control when the queues are getting filled, it's quite possible to have a very busy device (in this instance wlan0 RX'ing anything more than around 100mbit) queue enough packets to the devices' TX queue faster than the TX task can be scheduled to process packets.Bumping if_arge's default TX/RX ring buffer size from 128 to 1024 did the trick - no more packet drops on TX.Now I'm getting ~ 105mbit TCP RX in HT/40 5GHz hostap mode (since A-MPDU RX is implemented and working) and ~ 210mbit UDP RX before I begin to drop packets. Anything more than 210mbit starts resulting in the infamous "stuck beacon", but that could be for a variety of reasons. I don't think I'm saturating the PCI bus (read: the CPU scheduler does show about 30% idle clock cycles during a UDP RX test) so there's something else to be blamed.Next is figuring out whether there's some scheduling issues with the device TX/RX tasks.I find it quite creepy that I can get ~ 100mbit of 802.11n throughput to my macbook pro whilst lying in bed. But that's what 802.11n is for, right? :)

FreeBSD-HEAD on the PB92 + AR9280

Here's FreeBSD-HEAD up on the Atheros PB92 reference board (AR7242), complete with an AR9280 mini-PCIe NIC.I'm still only getting around 70mbit in HT/40 mode TCP tests and 90mbit in HT/40 UDP mode; but it's only (currently) connected at 100mbit ethernet. I'll tinker some more with gigabit-connected stuff soon. I hope the UDP throughput maxes out above 100mbit.It's a far cry from where it should be throughput-wise, but it's getting there.Another developer has -HEAD + a small patch working on the Ubiquiti Rocket M5 (AR7240 + AR9280 on-board), which is also great progress.# dmesg | grep athath0: at device 0.0 on pci0ath0: [HT] enabling HT modesath0: [HT] 2 RX streams; 2 TX streamsath0: AR9280 mac 128.2 RF5133 phy 13.0# uname -a FreeBSD TEST_AP 9.0-CURRENT FreeBSD 9.0-CURRENT #19 r220911:221321M: Mon May 2 22:46:32 WST 2011 adrian@pcbsd-3114:/data/freebsd/mips/head/obj/mipseb/mips.mipseb/data/freebsd/mips/head/src/sys/PB92 mips# ifconfig wlan0 list staADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 00:15:6d:84:05:52 1 157 240M 15.5 120 27094 58288 EP AQHTR HTCAP WPA WME8c:7b:9d:d6:65:ba 2 157 270M 21.5 0 56040 64688 EP AQHTRS RSN HTCAP WME#

FreeBSD-HEAD on the PB92 + AR9280

Here's FreeBSD-HEAD up on the Atheros PB92 reference board (AR7242), complete with an AR9280 mini-PCIe NIC.

I'm still only getting around 70mbit in HT/40 mode TCP tests and 90mbit in HT/40 UDP mode; but it's only (currently) connected at 100mbit ethernet. I'll tinker some more with gigabit-connected stuff soon. I hope the UDP throughput maxes out above 100mbit.

It's a far cry from where it should be throughput-wise, but it's getting there.

Another developer has -HEAD + a small patch working on the Ubiquiti Rocket M5 (AR7240 + AR9280 on-board), which is also great progress.


# dmesg | grep ath

ath0: at device 0.0 on pci0
ath0: [HT] enabling HT modes
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR9280 mac 128.2 RF5133 phy 13.0
# uname -a
FreeBSD TEST_AP 9.0-CURRENT FreeBSD 9.0-CURRENT #19 r220911:221321M: Mon May 2 22:46:32 WST 2011 adria
n@pcbsd-3114:/data/freebsd/mips/head/obj/mipseb/mips.mipseb/data/freebsd/mips/head/src/sys/PB92 mips
# ifconfig wlan0 list sta
ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG
00:15:6d:84:05:52 1 157 240M 15.5 120 27094 58288 EP AQHTR HTCAP WPA WME
8c:7b:9d:d6:65:ba 2 157 270M 21.5 0 56040 64688 EP AQHTRS RSN HTCAP WME
#

AR913x support in -HEAD, or TP-Link WR-1043nd

In summary:KDB: debugger backends: ddbKDB: current backend: ddbCopyright (c) 1992-2011 The FreeBSD Project.Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved.FreeBSD is a registered trademark of The FreeBSD Foundation.FreeBSD 9.0-CURRENT #6 r220911:221160M: Thu Apr 28 20:09:28 WST 2011 adrian@pcbsd-3114:/data/freebsd/mips/head/obj/mipseb/mips.mipseb/data/freebsd/mips/head/src/sys/TP-WN1043ND mipsreal memory = 33554432 (32768K bytes)avail memory = 21123072 (20MB)nexus0: clock0: on nexus0Timecounter "MIPS32" frequency 200000000 Hz quality 800Event timer "MIPS32" frequency 200000000 Hz quality 800apb0 at irq 4 on nexus0uart0: <16550 or compatible> on apb0uart0: console (115200,n,8,1)ehci0: at mem 0x1b000100-0x1bffffff irq 1 on nexus0usbus0: set host controller modeusbus0: EHCI version 1.0usbus0: set host controller modeusbus0: on ehci0arge0: at mem 0x19000000-0x19000fff irq 2 on nexus0arge0: Overriding MAC from EEPROMarge0: Ethernet address: 94:0c:6d:fe:4f:20arge1: at mem 0x1a000000-0x1a000fff irq 3 on nexus0device_attach: arge1 attach returned 22ath0: at mem 0x180c0000-0x180effff irq 0 on nexus0ath0: eeprom @ 0x1fff1000ath0: eeprom data @ 0xbfff1000ath0: [HT] enabling HT modesath0: [HT] 2 RX streams; 2 TX streamsath0: AR9130 mac 20.1 RF2133 phy 10.2spi0: at mem 0x1f000000-0x1f00000f on nexus0spibus0: on spi0mx25l0: at cs 0 on spibus0mx25l0: s25sl064a, sector 65536 bytes, 128 sectorsar71xx_wdog0: on nexus0ar71xx_wdog0: Previous reset was due to watchdog timeoutTimecounters tick every 1.000 msecusbus0: 480Mbps High Speed USB v2.0md0.uzip: 855 x 16384 blocksugen0.1: at usbus0uhub0: on usbus0Root mount waiting for: usbus0uhub0: 1 port with 1 removable, self poweredRoot mount waiting for: usbus0ugen0.2: at usbus0umass0: on usbus0umass0: SCSI over Bulk-Only; quirks = 0x0000Root mount waiting for: usbus0umass0:0:0:-1: Attached to scbus0Trying to mount root from ufs:/dev/md0 []...da0 at umass-sim0 bus 0 scbus0 target 0 lun 0da0: Removable Direct Access SCSI-0 deviceda0: 40.000MB/s transfersda0: 3835MB (7856127 512 byte sectors: 255H 63S/T 489C)Mounting from ufs:/dev/md0 failed with error 22.Trying to mount root from ufs:/dev/md0.uzip []...warning: no time-of-day clock registered, system time will not be set accuratelybridge0: Ethernet address: 06:26:1a:6f:d5:e7wlan0: Ethernet address: 00:19:e0:66:66:68And the wireless:# ifconfig wlan0wlan0: flags=8943 metric 0 mtu 1500 ether 00:19:e0:66:66:68 inet6 fe80::219:e0ff:fe66:6668%wlan0 prefixlen 64 scopeid 0x6 nd6 options=21 media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng status: running ssid CACHEBOY_RS channel 6 (2437 MHz 11g ht/40+) bssid 00:19:e0:66:66:68 regdomain ROW country AU ecm authmode WPA1+WPA2/802.11i privacy MIXED deftxkey 2 TKIP 2:128-bit txpower 30 scanvalid 60 protmode CTS -ampdutx ampdurx ampdulimit 64k -amsdu shortgi wme burst dtimperiod 1 -dfsI'll see about sneaking this into -HEAD soon.

AR913x support in -HEAD, or TP-Link WR-1043nd

In summary:

KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #6 r220911:221160M: Thu Apr 28 20:09:28 WST 2011
adrian@pcbsd-3114:/data/freebsd/mips/head/obj/mipseb/mips.mipseb/data/freebsd/mips/head/src/sys/TP-WN1043ND mips
real memory = 33554432 (32768K bytes)
avail memory = 21123072 (20MB)
nexus0:
clock0: on nexus0
Timecounter "MIPS32" frequency 200000000 Hz quality 800
Event timer "MIPS32" frequency 200000000 Hz quality 800
apb0 at irq 4 on nexus0
uart0: <16550 or compatible> on apb0
uart0: console (115200,n,8,1)
ehci0: at mem 0x1b000100-0x1bffffff irq 1 on nexus0
usbus0: set host controller mode
usbus0: EHCI version 1.0
usbus0: set host controller mode
usbus0: on ehci0
arge0: at mem 0x19000000-0x19000fff irq 2 on nexus0
arge0: Overriding MAC from EEPROM
arge0: Ethernet address: 94:0c:6d:fe:4f:20
arge1: at mem 0x1a000000-0x1a000fff irq 3 on nexus0
device_attach: arge1 attach returned 22
ath0: at mem 0x180c0000-0x180effff irq 0 on nexus0
ath0: eeprom @ 0x1fff1000
ath0: eeprom data @ 0xbfff1000
ath0: [HT] enabling HT modes
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR9130 mac 20.1 RF2133 phy 10.2
spi0: at mem 0x1f000000-0x1f00000f on nexus0
spibus0: on spi0
mx25l0: at cs 0 on spibus0
mx25l0: s25sl064a, sector 65536 bytes, 128 sectors
ar71xx_wdog0: on nexus0
ar71xx_wdog0: Previous reset was due to watchdog timeout
Timecounters tick every 1.000 msec
usbus0: 480Mbps High Speed USB v2.0
md0.uzip: 855 x 16384 blocks
ugen0.1: at usbus0
uhub0: on usbus0
Root mount waiting for: usbus0
uhub0: 1 port with 1 removable, self powered
Root mount waiting for: usbus0
ugen0.2: at usbus0
umass0: on usbus0
umass0: SCSI over Bulk-Only; quirks = 0x0000
Root mount waiting for: usbus0
umass0:0:0:-1: Attached to scbus0
Trying to mount root from ufs:/dev/md0 []...
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 3835MB (7856127 512 byte sectors: 255H 63S/T 489C)
Mounting from ufs:/dev/md0 failed with error 22.
Trying to mount root from ufs:/dev/md0.uzip []...
warning: no time-of-day clock registered, system time will not be set accurately
bridge0: Ethernet address: 06:26:1a:6f:d5:e7
wlan0: Ethernet address: 00:19:e0:66:66:68


And the wireless:

# ifconfig wlan0
wlan0: flags=8943 metric 0 mtu 1500
ether 00:19:e0:66:66:68
inet6 fe80::219:e0ff:fe66:6668%wlan0 prefixlen 64 scopeid 0x6
nd6 options=21
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng
status: running
ssid CACHEBOY_RS channel 6 (2437 MHz 11g ht/40+) bssid 00:19:e0:66:66:68
regdomain ROW country AU ecm authmode WPA1+WPA2/802.11i privacy MIXED
deftxkey 2 TKIP 2:128-bit txpower 30 scanvalid 60 protmode CTS
-ampdutx ampdurx ampdulimit 64k -amsdu shortgi wme burst dtimperiod 1
-dfs

I'll see about sneaking this into -HEAD soon.

11n TX and RX experiments..

My experiments so far are as follows (all in 5GHz mode - 2GHz is just too busy in my apartment complex):
  • FreeBSD <-> FreeBSD 11n is stable on the AR9160 and AR9220. TX aggregation is disabled, so it reaches around 35-40mbit in HT/20 and 45mbit in HT/40 mode. I'm getting MCS13 between an AP and STA which are in different rooms in my apartment. MCS15 is achievable if the units are close to each other.
  • Short-GI in 40MHz works fine.
  • When RX aggregation is enabled, and IEEE80211_AMPDU_AGE is enabled with net.wlan.ampdu_age set to 5 (it defaults to 500), I get ~ 55mbit RX in HT/20 and ~ 75mbit RX in HT/40 mode. There's problems with out of order packets that are appearing -before- the calculated block-ack window and net80211 is dropping those. I'll investigate why at some point.
  • FreeBSD works fine as an 11n AP, obviously with A-MPDU TX disabled.
There's lots of stuff that needs to be tested at this point, including:
  • 2GHz operation, obviously!
  • 11n and legacy co-operation.
  • Other chipsets - AR5416, AR9280, AR9285.
  • Behaviour in the presence of noise, busy channel, etc.
  • Make sure that HT/40 mode is -correctly- protecting frames on both channels and is correctly waiting to make sure both channels are free before transmitting!
And stuff that needs to be implemented before we enable it by default:
  • A-MPDU TX aggregation, for STA, AP, Mesh and adhoc modes - this one is really needed and is going to take some time to do.
  • HT RTS frame protection - I have code for this which I'll commit soon.

11n TX and RX experiments..

My experiments so far are as follows (all in 5GHz mode - 2GHz is just too busy in my apartment complex):
  • FreeBSD <-> FreeBSD 11n is stable on the AR9160 and AR9220. TX aggregation is disabled, so it reaches around 35-40mbit in HT/20 and 45mbit in HT/40 mode. I'm getting MCS13 between an AP and STA which are in different rooms in my apartment. MCS15 is achievable if the units are close to each other.
  • Short-GI in 40MHz works fine.
  • When RX aggregation is enabled, and IEEE80211_AMPDU_AGE is enabled with net.wlan.ampdu_age set to 5 (it defaults to 500), I get ~ 55mbit RX in HT/20 and ~ 75mbit RX in HT/40 mode. There's problems with out of order packets that are appearing -before- the calculated block-ack window and net80211 is dropping those. I'll investigate why at some point.
  • FreeBSD works fine as an 11n AP, obviously with A-MPDU TX disabled.
There's lots of stuff that needs to be tested at this point, including:
  • 2GHz operation, obviously!
  • 11n and legacy co-operation.
  • Other chipsets - AR5416, AR9280, AR9285.
  • Behaviour in the presence of noise, busy channel, etc.
  • Make sure that HT/40 mode is -correctly- protecting frames on both channels and is correctly waiting to make sure both channels are free before transmitting!
And stuff that needs to be implemented before we enable it by default:
  • A-MPDU TX aggregation, for STA, AP, Mesh and adhoc modes - this one is really needed and is going to take some time to do.
  • HT RTS frame protection - I have code for this which I'll commit soon.

(More) wireless hackery

So instead of doing what I should be doing, I did some more wifi hackery.
The short summary version (all 802.11g 2.4ghz testing):
  • AR5416 TX is still unhappy and unpredictable. It's also like that with ath9k. AR5416 RX is perfectly fine.
  • AR9160 TX/RX is fine.
  • AR9220 (Ubiquiti SR71-12 and Ubiquiti-SR71-15) TX/RX is now fine.
  • AR9280 closed and open-loop TX is fine, RX is also fine.
  • AR9285 TX/RX is fine and stable now.
I'll now go and test out 5GHz AP/STA modes with the above (where appropriate) and see how they behave. I hope they'll be just as stable now.
Bernard has been making inroads into fleshing out the missing parts of the net80211 802.11n support. Many thanks to him for taking the time to dissect the 802.11n spec, the Linux 802.11 stack and spend time with some APs determining what they're doing.

(More) wireless hackery

So instead of doing what I should be doing, I did some more wifi hackery.

The short summary version (all 802.11g 2.4ghz testing):
  • AR5416 TX is still unhappy and unpredictable. It's also like that with ath9k. AR5416 RX is perfectly fine.
  • AR9160 TX/RX is fine.
  • AR9220 (Ubiquiti SR71-12 and Ubiquiti-SR71-15) TX/RX is now fine.
  • AR9280 closed and open-loop TX is fine, RX is also fine.
  • AR9285 TX/RX is fine and stable now.
I'll now go and test out 5GHz AP/STA modes with the above (where appropriate) and see how they behave. I hope they'll be just as stable now.

Bernard has been making inroads into fleshing out the missing parts of the net80211 802.11n support. Many thanks to him for taking the time to dissect the 802.11n spec, the Linux 802.11 stack and spend time with some APs determining what they're doing.

More wireless hackery

I've had a busy week in the land of FreeBSD wireless driver hacking.
I've been porting over the AR9280 TX calibration changes from ath9k. The AR9280 NIC in my laptop loves it - but the AR9220 based SR71-12 is still unhappy. I'll go poke around and see if I can figure out what the problem is. I have some other AR9280 series NICs to try out.
I've been using hostap mode on the AR5416 and AR9160 and it still seems quite fine and stable.
I've ported over a number of changes to the AR9285 codebase from Linux ath9k. These include:
  • Fixing the TX power calibration curve code;
  • Handling a TX power offset at the beginning of the calibration curve;
  • Updating how the board is initially calibrated on reset;
  • Adding PA calibration.
I'm also trying to remove some of the duplicate code in the HAL that has crept up as chipset support was added.
I'm waiting to hear back from some other users about what effects it has on their setup. I still have to port over the (completely rewritten) radio board configuration code from ath9k that sets up all kinds of radio related gain, offset and various things. There's also software antenna diversity to port over. I hope that this all fixes the issues users have been reporting with AR9285 NICs just plain not working in a lot of instances - but working fine in others. I also hope it fixes the AR2427 support.
I'm still very unclear what may be up with the AR9280 support. The Ubiquiti high-powered cards tend to have strange EEPROM calibration settings, so it's quite possible FreeBSD just handles one of the options badly. That's going to take some time to figure out.
There's no point in getting 802.11n support enabled if I can't TX and RX cleanly, so I'm leaving 802.11n alone (for the most part) until the radios and MACs are behaving themselves.

More wireless hackery

I've had a busy week in the land of FreeBSD wireless driver hacking.

I've been porting over the AR9280 TX calibration changes from ath9k. The AR9280 NIC in my laptop loves it - but the AR9220 based SR71-12 is still unhappy. I'll go poke around and see if I can figure out what the problem is. I have some other AR9280 series NICs to try out.

I've been using hostap mode on the AR5416 and AR9160 and it still seems quite fine and stable.

I've ported over a number of changes to the AR9285 codebase from Linux ath9k. These include:
  • Fixing the TX power calibration curve code;
  • Handling a TX power offset at the beginning of the calibration curve;
  • Updating how the board is initially calibrated on reset;
  • Adding PA calibration.
I'm also trying to remove some of the duplicate code in the HAL that has crept up as chipset support was added.

I'm waiting to hear back from some other users about what effects it has on their setup. I still have to port over the (completely rewritten) radio board configuration code from ath9k that sets up all kinds of radio related gain, offset and various things. There's also software antenna diversity to port over. I hope that this all fixes the issues users have been reporting with AR9285 NICs just plain not working in a lot of instances - but working fine in others. I also hope it fixes the AR2427 support.

I'm still very unclear what may be up with the AR9280 support. The Ubiquiti high-powered cards tend to have strange EEPROM calibration settings, so it's quite possible FreeBSD just handles one of the options badly. That's going to take some time to figure out.

There's no point in getting 802.11n support enabled if I can't TX and RX cleanly, so I'm leaving 802.11n alone (for the most part) until the radios and MACs are behaving themselves.

AR9280 TX errors – why it’s important to care about how your hardware works..

One of the issues that I've been having with my AR9280 NIC is that MCS rates aren't being reliable.
Having fiddled with the TX power control with the AR9160 (and I'll write about that soon!) I remembered that badly-configured TX power control would result in the transmit side spitting out a (sometimes very) unclean spectral mask, with noise all over the place.
I did a little digging into how the AR9280 TX-side calibration works. It turns out that there's two methods of TX power control - closed-loop (with a power-detector ADC which compares the signal to a calibrated level) and open-loop (which I'm not yet sure about.) The AR9280 NIC that I have has the "open loop TX power control" bit set in the EEPROM, which indicates it needs open-loop TX power rather than closed-loop. A little digging shows that FreeBSD's HAL doesn't include closed-loop TX power control or any of the newer AR9280 calibration code (in particular the open-loop temperature compensation code.)
Long-story short, I've added the open-loop TX calibration and temperature compensation code from ath9k to the FreeBSD HAL (but I haven't yet committed it and won't until I figure out how to make it tidy) and suddenly all MCS rates TX perfectly fine.
So if you're using an AR9280 NIC, please keep a look out for when I commit this stuff and let me know if it improves things.

AR9280 TX errors – why it’s important to care about how your hardware works..

One of the issues that I've been having with my AR9280 NIC is that MCS rates aren't being reliable.

Having fiddled with the TX power control with the AR9160 (and I'll write about that soon!) I remembered that badly-configured TX power control would result in the transmit side spitting out a (sometimes very) unclean spectral mask, with noise all over the place.

I did a little digging into how the AR9280 TX-side calibration works. It turns out that there's two methods of TX power control - closed-loop (with a power-detector ADC which compares the signal to a calibrated level) and open-loop (which I'm not yet sure about.) The AR9280 NIC that I have has the "open loop TX power control" bit set in the EEPROM, which indicates it needs open-loop TX power rather than closed-loop. A little digging shows that FreeBSD's HAL doesn't include closed-loop TX power control or any of the newer AR9280 calibration code (in particular the open-loop temperature compensation code.)

Long-story short, I've added the open-loop TX calibration and temperature compensation code from ath9k to the FreeBSD HAL (but I haven't yet committed it and won't until I figure out how to make it tidy) and suddenly all MCS rates TX perfectly fine.

So if you're using an AR9280 NIC, please keep a look out for when I commit this stuff and let me know if it improves things.

AR9280/AR9285 support now working

I managed to find and fix the AR9280 and AR9285 support.Things that needed repairing:
  • Updating the AR9280 initvals to the Linux ath9k ones resolved the radio initialisation issues, making everything magically stable!
  • The v4k EEPROM code (for the AR9285/AR2427) needed some surgery to reflect what was really going on. In particular, the 8 bit radio bias values in the AR9280 (v14) EEPROM are actually lots of 4 bit values; so the bias values being written to the radio were woefully incorrect. This restored AR9285 stability and made the AR2427 function.
  • The AR9280 RF registers need an extra delay before being written to. I guess since the earlier radios are externally connected via single-bit IO (and thus shift registers are involved), the later radios are too. Without this delay, the AR9220 panics on my MIPS board and I would get occasional unexplained resets when I configured an AR9280 on my eeepc. This fix has resolved both those issues.
I have one more fix to integrate for the AR9220 init path so the Ubiquiti SR71-12 and SR71-15 work; then the AR9220 is supported.The AR2427 baseband seems to hang after a few hours of use, requiring a complete cold (power off) restart. There's some more initialisation code I need to port from ath9k and there's a lot of AR9280/AR9285 calibration code which I need to port over. I hope porting these two over will fix the stability issues that I was seeing. There's also some noise floor calibration fixes from ath9k which I need to integrate into the FreeBSD-HEAD tree.So, there's been quite a bit of progress! I've had reports from users that the AR9280, AR9285 and AR9220 support is now very stable; much more stable than before.

AR9280/AR9285 support now working

I managed to find and fix the AR9280 and AR9285 support.

Things that needed repairing:

  • Updating the AR9280 initvals to the Linux ath9k ones resolved the radio initialisation issues, making everything magically stable!
  • The v4k EEPROM code (for the AR9285/AR2427) needed some surgery to reflect what was really going on. In particular, the 8 bit radio bias values in the AR9280 (v14) EEPROM are actually lots of 4 bit values; so the bias values being written to the radio were woefully incorrect. This restored AR9285 stability and made the AR2427 function.
  • The AR9280 RF registers need an extra delay before being written to. I guess since the earlier radios are externally connected via single-bit IO (and thus shift registers are involved), the later radios are too. Without this delay, the AR9220 panics on my MIPS board and I would get occasional unexplained resets when I configured an AR9280 on my eeepc. This fix has resolved both those issues.
I have one more fix to integrate for the AR9220 init path so the Ubiquiti SR71-12 and SR71-15 work; then the AR9220 is supported.

The AR2427 baseband seems to hang after a few hours of use, requiring a complete cold (power off) restart. There's some more initialisation code I need to port from ath9k and there's a lot of AR9280/AR9285 calibration code which I need to port over. I hope porting these two over will fix the stability issues that I was seeing. There's also some noise floor calibration fixes from ath9k which I need to integrate into the FreeBSD-HEAD tree.

So, there's been quite a bit of progress! I've had reports from users that the AR9280, AR9285 and AR9220 support is now very stable; much more stable than before.

AR9220 support; why AR9280 is broken

I acquired a pair of shiny AR9220 minipci NICs last week - Ubiquiti SR71-12 and SR71-15. They're supposed to be like AR9280 but on PCI, not PCIe. Unfortunately they didn't work under FreeBSD. After some sleuthing (read: guessing), I stumbled across an ath9k commit which reworked some workaround for some AR9220's, which include the Ubiquiti SR71 versions.

https://patchwork.kernel.org/patch/90926/

There's also a bus error when reading a random register which is only referenced in a debug statement. That's a whole other bug to try and deal with.

But now I've verified that with both the AR9280 and the AR9220, the FreeBSD code is definitely tickling the radio wrong. Only one of the two radio chains is even active for the most part, and that chain seems to go deaf quite often, resulting in a baseband hang and chip reset. It also explains why I was getting absolutely shocking 11n performance out of it in my 11n branch.

AR9220 support; why AR9280 is broken

I acquired a pair of shiny AR9220 minipci NICs last week - Ubiquiti SR71-12 and SR71-15. They're supposed to be like AR9280 but on PCI, not PCIe. Unfortunately they didn't work under FreeBSD. After some sleuthing (read: guessing), I stumbled across an ath9k commit which reworked some workaround for some AR9220's, which include the Ubiquiti SR71 versions.https://patchwork.kernel.org/patch/90926/There's also a bus error when reading a random register which is only referenced in a debug statement. That's a whole other bug to try and deal with.But now I've verified that with both the AR9280 and the AR9220, the FreeBSD code is definitely tickling the radio wrong. Only one of the two radio chains is even active for the most part, and that chain seems to go deaf quite often, resulting in a baseband hang and chip reset. It also explains why I was getting absolutely shocking 11n performance out of it in my 11n branch.

802.11n update – WPA works

I traced down WPA not working to broken CCMP support in FreeBSD-HEAD.This has been broken for some time. It was introduced in r204364 which enabled the multicast key search. I'm not sure why it's broken - I'll have to go through the ath9k/ath5k code; maybe even madwifi has some more up to date code in this area.In any case, that's one less thing to worry about for now. I'm pretty sure that multi-VAP mode has more issues than this so I'll put that on hold for a while.Next - making the 11n TX path a run-time check rather than a compile-time check; then test it with legacy chipsets to ensure things haven't broken.

802.11n update – WPA works

I traced down WPA not working to broken CCMP support in FreeBSD-HEAD.

This has been broken for some time. It was introduced in r204364 which enabled the multicast key search. I'm not sure why it's broken - I'll have to go through the ath9k/ath5k code; maybe even madwifi has some more up to date code in this area.

In any case, that's one less thing to worry about for now. I'm pretty sure that multi-VAP mode has more issues than this so I'll put that on hold for a while.

Next - making the 11n TX path a run-time check rather than a compile-time check; then test it with legacy chipsets to ensure things haven't broken.