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.
Hi Adrian,
ReplyDeleteDid you ever get to fix the AR9220 issue? I have same thing and am disappointed as it's not working.
Thanks
Yup. AR9220's work fine for me!
ReplyDeleteIs this working for FreeBSD 8.x version as well? You are highly regarding in pfSense community for the work you do:
ReplyDeletehttp://forum.pfsense.org/index.php/topic,48132.msg253779.html#msg253779
Unfortunately, the AR9220 card is hanging and freezing in pfSense 2.1 right now. So, is AR9220 ONLY working for 9.x version of FreeBSD?
Types of error I get:
Apr 2 18:33:39 kernel: ath0: unable to reset hardware; hal status 3
Apr 2 18:33:41 kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 MHz, flags 0x480), hal status 3
Apr 2 18:33:45 kernel: ath0: ath_reset: unable to reset hardware; hal status 3
Apr 2 18:33:45 kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 MHz, flags 0x480), hal status 3
Apr 2 18:33:49 kernel: ath0: ath_reset: unable to reset hardware; hal status 3
Apr 2 18:33:49 kernel: ath0: ath_chan_set: unable to reset channel 11 (2462 MHz, flags 0x480), hal status 3
Apr 2 18:33:51 kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 MHz, flags 0x480), hal status 3
Apr 2 18:33:53 kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 MHz, flags 0x480), hal status 3
Apr 2 18:33:55 kernel: ath0: unable to reset hardware; hal status 3
Apr 2 18:34:06 php: /status_interfaces.php: The command '/sbin/dhclient -c /var/etc/dhclient_opt2.conf ath0_wlan0 > /tmp/ath0_wlan0_output > /tmp/ath0_wlan0_error_output' returned exit code '1', the output was ''
Apr 2 18:34:08 kernel: ath0: unable to reset hardware; hal status 3
Thanks a bunch.
highly *regarded* :-)
ReplyDeleteHiya!
ReplyDeleteWow, I'm blushing a bit. :)
The AR9220 fixes are in 9.x, yes. I have a general rule at the moment of "only backport what is so painfully obvious it hurts." Since it's just me doing this, I treat the major FreeBSD releases as regression points for the ath/net80211 code. So, I don't currently plan on backporting my ath/ath_hal fixes from 9 to 8 (or 7) at the moment as I wanted to make sure that if it didn't work for people in 9, they could try 8. Same with -HEAD - I won't be backporting the 802.11n stuff from -HEAD to -9 any time soon, as I'd like to ensure that whatever is in -9 is stable.
If someone/some group wanted to take responsibility of backporting the ath/hal/net80211 changes from -HEAD -> 9 -> 8 (minus all the 802.11n specific additions) then I'll definitely work with them to get the changes into the tree. But they have to do the testing and handle support queries when it breaks. :-)
As for the AR9220 - there's likely a very simple fix or two that needs to be backported from -9 to -8 to get the AR9220 to work.
Thanks for the input again.
ReplyDeleteWould the fix require simple file transfer or few lines changed? I don't mind getting down into the code if you can provide a bit of insight as to which files might be involved. If it's more complicated then I'd rather store this mini pci card for later use.
Best,