Bug 194336 - AR9300 pci wireless card not working
Summary: AR9300 pci wireless card not working
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: 10.1-STABLE
Hardware: amd64 Any
: Normal Affects Only Me
Assignee: freebsd-wireless mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-13 19:04 UTC by lukek
Modified: 2019-01-27 14:28 UTC (History)
13 users (show)

See Also:


Attachments
Add a regulatory domain for Canada (891 bytes, patch)
2016-01-20 19:10 UTC, Jung-uk Kim
no flags Details | Diff
Add a regulatory domain for Canada (673 bytes, patch)
2016-01-20 19:53 UTC, Jung-uk Kim
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description lukek 2014-10-13 19:04:00 UTC
My wireless Atheros pci card is not working. It may have something to do with the HAL_CTRY_CODE value in ah_regdomain.c:ath_hal_init_channels().
Debugging in ath_hal_init_channels() shows these values:
    HAL_CTRY_CODE = 0
    HAL_REG_DOMAIN = 240
    return status of 12 (indicating invalid fcn parameter value?)


-----------------------------uname -a------------------------------
FreeBSD 10.1-RELEASE-p2 #12 02b9957(stable/10)
root@bellicose:/usr/obj/root/pcbsd-build-10-STABLE/git/freebsd/sys/GENERIC
amd64

-----------------------------pciconf--------------------------------
none2@pci0:4:0:0:       class=0x028000 card=0x3a7e1186 chip=0x0030168c
rev=0x01 hdr=0x00
    vendor     = 'Atheros Communications Inc.'
    device     = 'AR9300 Wireless LAN adaptor'
    class      = network
-----------------------------dmesg---------------------------------
hdac1: <ATI (0x9902) HDA Controller> mem 0xfeb44000-0xfeb47fff irq 18 at
device 1.1 on pci0
hdac1: hdac_get_capabilities: Invalid corb size (0)
device_attach: hdac1 attach returned 6
ath0: <Atheros AR938x> mem 0xfea00000-0xfea1ffff irq 16 at device 0.0 on
pci4
ar9300_set_stub_functions: setting stub functions
ar9300_set_stub_functions: setting stub functions
ar9300_attach: calling ar9300_hw_attach
ar9300_hw_attach: calling ar9300_eeprom_attach
ar9300_flash_map: unimplemented for now
Restoring Cal data from DRAM
Restoring Cal data from EEPROM
ar9300_hw_attach: ar9300_eeprom_attach returned 0
ath0: RX status length: 48
ath0: RX buffer size: 4096
ath0: TX descriptor length: 128
ath0: TX status length: 36
ath0: TX buffers per descriptor: 4
ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0
ath0: ath_getchannels: unable to collect channel list from hal, status
12
device_attach: ath0 attach returned 22
hdac1: <ATI (0x9902) HDA Controller> mem 0xfeb44000-0xfeb47fff irq 18 at
device 1.1 on pci0
hdac1: hdac_get_capabilities: Invalid corb size (0)
device_attach: hdac1 attach returned 6
ath0: <Atheros AR938x> mem 0xfea00000-0xfea1ffff irq 16 at device 0.0 on
pci4
ar9300_set_stub_functions: setting stub functions
ar9300_set_stub_functions: setting stub functions
ar9300_attach: calling ar9300_hw_attach
ar9300_hw_attach: calling ar9300_eeprom_attach
ar9300_flash_map: unimplemented for now
Restoring Cal data from DRAM
Restoring Cal data from EEPROM
ar9300_hw_attach: ar9300_eeprom_attach returned 0
ath0: RX status length: 48
ath0: RX buffer size: 4096
ath0: TX descriptor length: 128
ath0: TX status length: 36
ath0: TX buffers per descriptor: 4
ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0
ath0: ath_getchannels: unable to collect channel list from hal, status
12
device_attach: ath0 attach returned 22
Comment 1 lukek 2014-10-13 19:39:45 UTC
Card was bought in Canada if it matters. I can assist in testing patches etc.
Comment 2 lukek 2014-10-16 02:47:07 UTC
By recompiling the kernel to remove all 'ath' related entries I am able to load the if_ath_pci manually and get an ath0 device to show up. If I then attempt to run 'service netif restart' I get a working connection breifly but the following messages fill up the log and soon freeze my system:

ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
ath0: ath_edma_rxfifo_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=1, nbufs=128?
Comment 3 lukek 2014-10-17 04:07:02 UTC
(In reply to lukek from comment #2)
> By recompiling the kernel to remove all 'ath' related entries I am able to
> load the if_ath_pci manually and get an ath0 device to show up. If I then
> attempt to run 'service netif restart' I get a working connection breifly
> but the following messages fill up the log and soon freeze my system:
> 
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
> ath0: ath_edma_rxfifo_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=1, nbufs=128?

Neglected to mention I also set the Country to CA for the wlan0 interface
Comment 4 Adrian Chadd freebsd_committer 2014-10-17 07:59:10 UTC
Hm, you have to build the module with ATH_ENABLE_11N in your kernel.

You also have to build the module the real way,ie:

cd /usr/src
make buildkernel KERNCONF=<CONFIG FILE NAME>

.. going cd sys/modules/ath && make won't cut it - it doesn't pull in the config headers (ie, all the opt_xxx.h in your kernel build directory) with the configuration options.
Comment 5 Adrian Chadd freebsd_committer 2014-10-17 08:07:33 UTC
I'm confused. So, HAL_REG_DOMAIN=0xf0 is one of the japan regdomains (MKK3_MKKA).

But there's no mapping from that to a net80211 country.

Ah, because it's some new code that I don't yet know about.

Is this some card/laptop from Japan?
Comment 6 lukek 2014-10-17 12:00:07 UTC
(In reply to Adrian Chadd from comment #4)
> Hm, you have to build the module with ATH_ENABLE_11N in your kernel.
> 
> You also have to build the module the real way,ie:
> 
> cd /usr/src
> make buildkernel KERNCONF=<CONFIG FILE NAME>
> 
> .. going cd sys/modules/ath && make won't cut it - it doesn't pull in the
> config headers (ie, all the opt_xxx.h in your kernel build directory) with
> the configuration options

I did indeed build the kernel and install it, but since I don't have the ATH_ENABLE_11N in my kernel maybe that is the reason for the last mentioned infinite errors.
Comment 7 lukek 2014-10-17 12:03:09 UTC
(In reply to Adrian Chadd from comment #5)
> I'm confused. So, HAL_REG_DOMAIN=0xf0 is one of the japan regdomains
> (MKK3_MKKA).
> 
> But there's no mapping from that to a net80211 country.
> 
> Ah, because it's some new code that I don't yet know about.
> 
> Is this some card/laptop from Japan?

Very strange. It is a PCI-E card I bought in Ottawa Canada from Canada Computers. Thanks for looking into this.
Comment 8 Marcus von Appen freebsd_committer freebsd_triage 2015-02-18 11:54:22 UTC
Updated 10.1-BETA and 10.1-RC versioned bugs to 10.1-STABLE.
Comment 9 Glen Barber freebsd_committer 2015-07-07 15:37:56 UTC
Is this still an issue?
Comment 10 Andrew 2015-07-30 01:58:43 UTC
Hi, I believe I am receiving the same error as well on Pfsense 2.2.4 (FreeBSD 10.1-RELEASE-p15) with a D-Link wireless N600 card (DWA-566) 2 channel pcie card. Let me know if you require anymore info.


-----------------------------dmesg---------------------------------
ath0: <Atheros AR938x> mem 0xf0600000-0xf061ffff irq 16 at device 0.0 on pci32
ar9300_attach: calling ar9300_hw_attach
ar9300_hw_attach: calling ar9300_eeprom_attach
ar9300_flash_map: unimplemented for now
Restoring Cal data from DRAM
Restoring Cal data from EEPROM
ar9300_hw_attach: ar9300_eeprom_attach returned 0
ath0: ath_getchannels: unable to collect channel list from hal, status 12
device_attach: ath0 attach returned 22
----------------------------------------------------------------------

Thanks
Comment 11 lukek 2015-07-30 12:42:22 UTC
I still receive the following error as I originally posted using 
the snapshot: FreeBSD-11.0-CURRENT-amd64-20150716-r285616-memstick.img

dmesg:
r9300_hw_attach: ar9300_eeprom_attach returned 0
ath0: ath_getchannels: unable to collect channel list from hal, status 12
device_attach: ath0 attach returned 22
Comment 12 Greg Becker 2015-12-22 13:07:31 UTC
I am seeing this problem (i.e., "unable to collect...") with a TP-LINK TL-WDN4800 I picked up from from Frys the other day in Austin, TX.

After getting nowhere searching the web, I crafted the following patch and low and behold the card now appears to work just fine:


Index: sys/dev/ath/if_ath.c
===================================================================
--- sys/dev/ath/if_ath.c        (revision 292515)
+++ sys/dev/ath/if_ath.c        (working copy)
@@ -5631,11 +5631,11 @@
        struct ath_hal *ah = sc->sc_ah;
 
        DPRINTF(sc, ATH_DEBUG_REGDOMAIN, "%s: use rd %u cc %d\n",
-           __func__, SKU_DEBUG, CTRY_DEFAULT);
+           __func__, SKU_DEBUG, CTRY_UNITED_STATES);
 
        /* XXX check return */
        (void) ath_hal_getchannels(ah, chans, maxchans, nchans,
-           HAL_MODE_ALL, CTRY_DEFAULT, SKU_DEBUG, AH_TRUE);
+           HAL_MODE_ALL, CTRY_UNITED_STATES, SKU_DEBUG, AH_TRUE);
 
 }
 
@@ -5651,7 +5651,7 @@
         * Collect channel set based on EEPROM contents.
         */
        status = ath_hal_init_channels(ah, ic->ic_channels, IEEE80211_CHAN_MAX,
-           &ic->ic_nchans, HAL_MODE_ALL, CTRY_DEFAULT, SKU_NONE, AH_TRUE);
+           &ic->ic_nchans, HAL_MODE_ALL, CTRY_UNITED_STATES, SKU_NONE, AH_TRUE);
        if (status != HAL_OK) {
                if_printf(ifp, "%s: unable to collect channel list from hal, "
                    "status %d\n", __func__, status);




Dec 21 07:41:09 harper kernel: ath0: <Atheros AR938x> mem 0xfb500000-0xfb51ffff irq 32 at device 0.0 on pci3
Dec 21 07:41:09 harper kernel: ar9300_set_stub_functions: setting stub functions
Dec 21 07:41:09 harper kernel: ar9300_set_stub_functions: setting stub functions
Dec 21 07:41:09 harper kernel: ar9300_attach: calling ar9300_hw_attach
Dec 21 07:41:09 harper kernel: ar9300_hw_attach: calling ar9300_eeprom_attach
Dec 21 07:41:09 harper kernel: ar9300_flash_map: unimplemented for now
Dec 21 07:41:09 harper kernel: Restoring Cal data from DRAM
Dec 21 07:41:09 harper kernel: Restoring Cal data from EEPROM
Dec 21 07:41:09 harper kernel: ar9300_hw_attach: ar9300_eeprom_attach returned 0
Dec 21 07:41:09 harper kernel: ath0: RX status length: 48
Dec 21 07:41:09 harper kernel: ath0: RX buffer size: 4096
Dec 21 07:41:09 harper kernel: ath0: TX descriptor length: 128
Dec 21 07:41:09 harper kernel: ath0: TX status length: 36
Dec 21 07:41:09 harper kernel: ath0: TX buffers per descriptor: 4
Dec 21 07:41:09 harper kernel: ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0
Dec 21 07:41:09 harper kernel: ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries
Dec 21 07:41:09 harper kernel: ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries
Dec 21 07:41:09 harper kernel: ath0: [HT] enabling HT modes
Dec 21 07:41:09 harper kernel: ath0: [HT] enabling short-GI in 20MHz mode
Dec 21 07:41:09 harper kernel: ath0: [HT] 1 stream STBC receive enabled
Dec 21 07:41:09 harper kernel: ath0: [HT] 1 stream STBC transmit enabled
Dec 21 07:41:09 harper kernel: ath0: [HT] 3 RX streams; 3 TX streams
Dec 21 07:41:09 harper kernel: ath0: AR9380 mac 448.3 RF5110 phy 0.0
Dec 21 07:41:09 harper kernel: ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000
Dec 21 07:41:09 harper devd: Executing '/etc/pccard_ether ath0 start'
Dec 21 07:41:10 harper kernel: wlan0: Ethernet address: f4:f2:6d:b5:42:25
Dec 21 07:41:10 harper devd: Executing '/etc/pccard_ether ath0 start'
Dec 21 07:41:10 harper devd: Executing '/etc/pccard_ether wlan0 start'
Comment 13 Adrian Chadd freebsd_committer 2015-12-22 14:40:16 UTC
sorry, keep pestering me until I figure out which country code to put this NIC in. :)
Comment 14 Greg Becker 2015-12-23 14:40:18 UTC
Thanks Adrian!

For what it's worth, here's the ATH_DEBUG output when it fails, hope this helps!

FreeBSD harper.cc.codeconcepts.com 10.2-STABLE FreeBSD 10.2-STABLE #13 r292515M: Mon Dec 21 07:20:01 CST 2015     root@harper.cc.codeconcepts.com:/usr/obj/usr/src/sys/HARPER  amd64

I should note, this log output is from the time I built directly from the sys/modules/ath directory, which with my patch allowed the device to attach, but I then ran into the "rxfifo alloc" issue and had to rebuild from /usr/src in the usual way in order to get a working device.


Dec 21 06:36:08 harper kernel: ath0: <Atheros AR938x> mem 0xfb500000-0xfb51ffff irq 32 at device 0.0 on pci3
Dec 21 06:36:08 harper kernel: ar9300_set_stub_functions: setting stub functions
Dec 21 06:36:08 harper kernel: ar9300_set_stub_functions: setting stub functions
Dec 21 06:36:08 harper kernel: ar9300_set_power_mode: AWAKE -> AWAKE (set chip )
Dec 21 06:36:08 harper kernel: ar9300_attach: ah_serialise_reg_war is 0
Dec 21 06:36:08 harper kernel: ar9300_attach: This Mac Chip Rev 0x1c0.3 is 
Dec 21 06:36:08 harper kernel: ar9300_attach: calling ar9300_hw_attach
Dec 21 06:36:08 harper kernel: ar9300_hw_attach: calling ar9300_eeprom_attach
Dec 21 06:36:08 harper kernel: ar9300_flash_map: unimplemented for now
Dec 21 06:36:08 harper kernel: Restoring Cal data from DRAM
Dec 21 06:36:08 harper kernel: Restoring Cal data from EEPROM
Dec 21 06:36:08 harper kernel: ar9300_eeprom_restore_internal_address: Found block at 3ff: code=3 ref=5 length=564 major=2 minor=20
Dec 21 06:36:08 harper kernel: ar9300_eeprom_restore_internal_address: checksum a9ff a9ff
Dec 21 06:36:08 harper kernel: ar9300_eeprom_restore_internal_address: restore eeprom 0: block, reference 5, length 564
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 0: spot=2 offset=2 length=6
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 8: spot=24 offset=16 length=5
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 15: spot=43 offset=14 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 18: spot=61 offset=17 length=12
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 32: spot=94 offset=21 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 35: spot=102 offset=7 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 38: spot=136 offset=33 length=2
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 42: spot=141 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 47: spot=147 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 52: spot=153 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 57: spot=159 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 62: spot=165 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 67: spot=171 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 72: spot=177 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 77: spot=183 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 82: spot=189 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 87: spot=198 offset=6 length=8
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 97: spot=273 offset=67 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 100: spot=287 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 103: spot=294 offset=6 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 106: spot=301 offset=6 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 109: spot=324 offset=22 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 112: spot=328 offset=3 length=9
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 123: spot=344 offset=7 length=9
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 134: spot=356 offset=3 length=62
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 198: spot=432 offset=14 length=10
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 210: spot=459 offset=17 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 213: spot=489 offset=29 length=25
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 240: spot=517 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 245: spot=523 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 250: spot=529 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 255: spot=535 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 260: spot=541 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 265: spot=547 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 270: spot=553 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 275: spot=559 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 280: spot=565 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 285: spot=571 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 290: spot=577 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 295: spot=583 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 300: spot=589 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 305: spot=595 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 310: spot=601 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 315: spot=607 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 320: spot=613 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 325: spot=619 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 330: spot=625 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 335: spot=631 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 340: spot=637 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 345: spot=643 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 350: spot=649 offset=3 length=3
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 355: spot=656 offset=4 length=23
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 380: spot=716 offset=37 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 383: spot=730 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 386: spot=744 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 389: spot=758 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 392: spot=772 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 395: spot=786 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 398: spot=800 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 401: spot=814 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 404: spot=828 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 407: spot=842 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 410: spot=856 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 413: spot=870 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 416: spot=884 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 419: spot=898 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 422: spot=912 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 425: spot=926 offset=13 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 428: spot=945 offset=18 length=10
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 440: spot=959 offset=4 length=1
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 443: spot=967 offset=7 length=25
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 470: spot=995 offset=3 length=13
Dec 21 06:36:08 harper kernel: ar9300_uncompress_block: Restore at 485: spot=1011 offset=3 length=77
Dec 21 06:36:08 harper kernel: ar9300_hw_attach: ar9300_eeprom_attach returned 0
Dec 21 06:36:08 harper kernel: ar9300_enable_mib_counters: Enable MIB counters
Dec 21 06:36:08 harper kernel: ath0: RX status length: 48
Dec 21 06:36:08 harper kernel: ath0: RX buffer size: 4096
Dec 21 06:36:08 harper kernel: ath0: TX descriptor length: 128
Dec 21 06:36:08 harper kernel: ath0: TX status length: 36
Dec 21 06:36:08 harper kernel: ath0: TX buffers per descriptor: 4
Dec 21 06:36:08 harper kernel: ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0
Dec 21 06:36:08 harper kernel: getchannels: cc 0 regDmn 0xf0 mode 0xffffff ecm
Dec 21 06:36:08 harper kernel: isEepromValid: invalid regulatory domain/country code 0x14
Dec 21 06:36:08 harper kernel: getregstate: invalid EEPROM contents
Dec 21 06:36:08 harper kernel: ath0: ath_getchannels: unable to collect channel list from hal, status 12
Dec 21 06:36:08 harper kernel: ar9300_set_power_mode: AWAKE -> AWAKE (set chip )
Dec 21 06:36:08 harper kernel: ar9300_ani_detach: Detaching Ani
Dec 21 06:36:08 harper kernel: ar9300_disable_mib_counters: Disabling MIB counters
Dec 21 06:36:08 harper kernel: ar9300_set_power_mode: AWAKE -> FULL-SLEEP (set chip )
Dec 21 06:36:08 harper kernel: device_attach: ath0 attach returned 22
Comment 15 Chris 2016-01-20 17:12:17 UTC
Hello, I am experiencing the same issue with a Canadian purchased card D-Link DWA-566 Wireless N 300 Dual Band PCI Express Desktop Adapter. This card was purchased in Canada.

Changing the CTRY_DEFAULT, as  Greg Becker states, to CTRY_CANADA or CTRY_UNITED_STATES resolves the error and allows the card to function properly.

I tried it on 10.1, 10.2 and 11.0
Comment 16 Jung-uk Kim freebsd_committer 2016-01-20 19:10:59 UTC
Created attachment 165875 [details]
Add a regulatory domain for Canada

This should be more appropriate fix.
Comment 17 Jung-uk Kim freebsd_committer 2016-01-20 19:53:53 UTC
Created attachment 165880 [details]
Add a regulatory domain for Canada

Adding a patch for ah_rd_domains.h.  Note the new entry is coped from FCC2.
Comment 18 Chris 2016-01-20 20:51:56 UTC
After applying the 2 patches by  Jung-uk Kim I get the following;

dmesg | grep ath
ath0: <Atheros AR938x> mem 0xfebe0000-0xfebfffff irq 17 at device 0.0 on pci4
ath0: RX status length: 48
ath0: RX buffer size: 4096
ath0: TX descriptor length: 128
ath0: TX status length: 36
ath0: TX buffers per descriptor: 4
ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries
ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 stream STBC transmit enabled
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR9380 mac 448.3 RF5110 phy 0.0
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000
ath0: <Atheros AR938x> mem 0xfebe0000-0xfebfffff irq 17 at device 0.0 on pci4
ath0: RX status length: 48
ath0: RX buffer size: 4096
ath0: TX descriptor length: 128
ath0: TX status length: 36
ath0: TX buffers per descriptor: 4
ath0: ath_getchannels: unable to collect channel list from hal, status 12
device_attach: ath0 attach returned 22
ath0: <Atheros AR938x> mem 0xfebe0000-0xfebfffff irq 17 at device 0.0 on pci4
ath0: RX status length: 48
ath0: RX buffer size: 4096
ath0: TX descriptor length: 128
ath0: TX status length: 36
ath0: TX buffers per descriptor: 4
ath0: ath_getchannels: unable to collect channel list from hal, status 12
device_attach: ath0 attach returned 22
Comment 19 Jung-uk Kim freebsd_committer 2016-01-20 21:03:07 UTC
(In reply to Chris from comment #18)
Hmm...  Please recompile kernel with "options AH_DEBUG".

https://wiki.freebsd.org/dev/ath%284%29/Debugging

We need to see "isEepromValid: invalid regulatory domain/country code 0xNN" like comment #14.
Comment 20 Jung-uk Kim freebsd_committer 2016-02-02 18:49:24 UTC
(In reply to Chris from comment #18)
I bought a card for myself.

http://www.newegg.com/Product/Product.aspx?Item=9SIA4P03CW2924

The card is marked for US but the regdomain is actually set for 0x14.  With my patch, it actually works fine.  Now we really need to find a correct entry for FCC6.
Comment 21 Chris 2016-02-05 20:42:14 UTC
I ordered the T-P Link Card as Jung-uk Kim indicated and it works. I installed it on my system in place of the D-Link.

The D-Link does not. They both have the same Atheros AR938x

I added option AH_DEBUG in my kernel and rebuilt but I get the following when I try anything.

athdebug: sysctl-get(dev.ath.0.debug): No such file or directory


Is there a more detailed HowTo on athdebug. I am a complete noob when it comes to drivers.
Comment 22 Bobby Whitley 2016-03-26 20:49:01 UTC
(In reply to Greg Becker from comment #12)

I have the same tl-wdn4800 card.  Greg how do I install your fix?
Comment 23 Adrian Chadd freebsd_committer 2016-03-27 22:45:31 UTC
https://wiki.freebsd.org/dev/ath%284%29/Debugging has information about debugging.

You need to use -i wlan0 (after creating wlan0) for it to work.


-adrian
Comment 24 Adrian Chadd freebsd_committer 2016-03-27 22:50:32 UTC
Hi!

We need a new bug created for the regulatory domain entry for canada.

The reference driver I have does more for FCC6:

* need to check eeprom REG_EXT_FCC bits for REG_EXT_FCC_CH_144 and whatever the heck ah_config.ath_hal_ch144 gets loaded with to see if we /can/ use the device in this regdomain

EnumRd:

        FCC6_FCCA       = 0x14,         /* Canada for AP only*/
        FCC6_WORLD      = 0x23,         /* Australia for AP only*/
        FCC6            = 0x0610,       /* Canada & Australia */
        FCC7            = 0x0710,       /* Same as FCC6 but with higher power */

Then RegDomainPairs:


        {FCC6_FCCA,     FCC6,           FCCA,           NO_REQ, NO_REQ, PSCAN_DEFER, 0 },
        {FCC7_FCCA,     FCC7,           FCCA,           NO_REQ, NO_REQ, PSCAN_DEFER, 0 },
        {FCC6_WORLD,    FCC6,           WORLD,          NO_REQ, NO_REQ, PSCAN_DEFER, 0 },

Then Countries:

    {CTRY_ARGENTINA2,  FCC6_WORLD,    "AR", "ARGENTINA2",     YES,  NO,  NO, YES, YES, YES, YES, 7000 },
    {CTRY_AUSTRALIA2,  FCC6_WORLD,    "AU", "AUSTRALIA2",     YES, YES, YES, YES, YES, YES, YES, 7000 },
    {CTRY_CANADA2,     FCC6_FCCA,     "CA", "CANADA2",        YES, YES, YES, YES, YES, YES, YES, 7000 },
    {CTRY_UNITED_STATES2, FCC6_FCCA,  "US", "UNITED STATES2",  YES, YES, YES, YES, YES, YES, YES, 7000 },

.. then the actual regdomain entries:

        {FCC6, FCC, DFS_FCC3, PSCAN_FCC, NO_REQ,
         BM(F8_5180_5240, F5_5260_5320, F1_5500_5580, F2_5660_5720, F6_5745_5825, -1, -1, -1, -1, -1, -1, -1),
         BM(T7_5210_5210, T3_5250_5290, T2_5760_5800, -1, -1, -1, -1, -1, -1, -1, -1, -1),
         BM(T7_5200_5200, T1_5240_5240, T2_5280_5280, T1_5765_5805, -1, -1, -1, -1, -1, -1, -1, -1),
         BMZERO,
         BMZERO,
         CHAN_TURBO_G_BMZERO
     },

        {FCC7, FCC, DFS_FCC3, PSCAN_FCC, NO_REQ,
         BM(F11_5180_5240, F8_5260_5320, F2_5500_5580, F3_5660_5720, F6_5745_5825, -1, -1, -1, -1, -1, -1, -1),
         BM(T11_5210_5210, T5_5250_5290, T2_5760_5800, -1, -1, -1, -1, -1, -1, -1, -1, -1),
         BM(T9_5200_5200, T2_5240_5240, T3_5280_5280, T1_5765_5805, -1, -1, -1, -1, -1, -1, -1, -1),
         BMZERO,
         BMZERO,
         CHAN_TURBO_G_BMZERO
     },

so it is a little more complicated. :-P
Comment 25 Adrian Chadd freebsd_committer 2016-03-27 22:51:57 UTC
ok, for the original poster:

        MKK3_MKKA       = 0xF0,         /* Japan UNI-1 even + MKKA */


        /* MKK3 */
        {MKK3_MKKA,     MKK3,           MKKA,           DISALLOW_ADHOC_11A_TURB | NEED_NFC | LIMIT_FRAME_4MS, NEED_NFC , PSCAN_MKKA, CTRY_JAPAN25 },

    {CTRY_JAPAN25,     MKK3_MKKA,     "JP", "JAPAN25",        YES,  NO,  NO, YES, YES, YES, YES, 7000 },

.. Yeah, sigh, a lot of weird crap in here :(
Comment 26 Adrian Chadd freebsd_committer 2016-09-25 22:18:51 UTC
Hi!

Try r306323 !


-a
Comment 27 Eli Gwynn 2017-06-12 20:19:46 UTC
I have zero experience with wlan drivers, but this thread was the key to making my hardware work, so I figured I'd add my own details here in case they are helpful to someone else. My use case involves the wlan device in hostap mode bridged with my wired nic to expand the wifi coverage in my house.

--- My Hardware

Rosewill RNWD-N9003PCE (Ver 1.0)

- WikiDevi: https://wikidevi.com/wiki/Rosewill_N900PCE
- Amazon: https://www.amazon.com/gp/product/B009VKON0S

FWIW, I live in the US and didn't have any inclination that I might end up with a non-US device. The only hint that my device might be non-US (Canadian?) is that some of the packaging is doubled up in French.

--- pciconf

ath0@pci0:2:0:0:        class=0x028000 card=0x3112168c chip=0x0030168c rev=0x01 hdr=0x00
    vendor     = 'Qualcomm Atheros'
    device     = 'AR93xx Wireless Network Adapter'
    class      = network

--- dmesg (pre-patch)

Jun 11 09:51:02 zfs kernel: pcib2: <ACPI PCI-PCI bridge> irq 17 at device 28.5 on pci0
Jun 11 09:51:02 zfs kernel: pci2: <ACPI PCI bus> on pcib2
Jun 11 09:51:02 zfs kernel: ath0: <Atheros AR938x> mem 0xdf100000-0xdf11ffff irq 17 at device 0.0 on pci2
Jun 11 09:51:02 zfs kernel: ar9300_attach: calling ar9300_hw_attach
Jun 11 09:51:02 zfs kernel: ar9300_hw_attach: calling ar9300_eeprom_attach
Jun 11 09:51:02 zfs kernel: ar9300_flash_map: unimplemented for now
Jun 11 09:51:02 zfs kernel: Restoring Cal data from DRAM
Jun 11 09:51:02 zfs kernel: Restoring Cal data from EEPROM
Jun 11 09:51:02 zfs kernel: ar9300_hw_attach: ar9300_eeprom_attach returned 0
Jun 11 09:51:02 zfs kernel: ath0: ath_getchannels: unable to collect channel list from hal, status 12
Jun 11 09:51:02 zfs kernel: device_attach: ath0 attach returned 22

--- Steps I took

1. I ran `make buildworld` in order to get my build tools back in sync with my sources
2. I added `options AH_DEBUG` to my kernel's conf
3. I ran `make buildkernel`, `make installkernel`, and rebooted
4. I ran `sysctl hw.ath.hal.debug=1`
5. I used `devctl detach pci2` and `devctl attach pci2` to trigger the malfunction again
6. I observed that my device was also showing up as

> Jun 12 14:53:41 zfs kernel: isEepromValid: invalid regulatory domain/country code 0x14

7. I applied both of Jung-uk Kim's attached patches (https://bugs.freebsd.org/bugzilla/attachment.cgi?id=165875&action=diff and https://bugs.freebsd.org/bugzilla/attachment.cgi?id=165880&action=diff)
8. I ran `make buildkernel` and `make installkernel` again
9. I rebooted and then my card worked

--- PS

Are the solutions presented in this thread good enough to make it into the mainline driver? I'd hate to have to do this again when next I do a freebsd-update.

Thanks to everyone for all the good work!
Comment 28 Kamil Choudhury 2017-08-14 01:19:40 UTC
r306323 works! 

Unfortunately, 10 months after commit, it hasn't made it into any production release.
Comment 29 Paul Armstrong 2017-08-25 22:42:15 UTC
I just successfully used r306323 to make my AR9380 work, so another thumbs up on this patch.

ath0@pci0:32:0:0:	class=0x028000 card=0x3112168c chip=0x0030168c rev=0x01 hdr=0x00
    vendor     = 'Qualcomm Atheros'
    device     = 'AR93xx Wireless Network Adapter'
    class      = network

ath0: <Atheros AR938x> mem 0xf0800000-0xf081ffff irq 16 at device 0.0 on pci1
ar9300_attach: calling ar9300_hw_attach
ar9300_hw_attach: calling ar9300_eeprom_attach
ar9300_flash_map: unimplemented for now
Restoring Cal data from DRAM
Restoring Cal data from EEPROM
ar9300_hw_attach: ar9300_eeprom_attach returned 0
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 stream STBC transmit enabled
ath0: [HT] LDPC transmit/receive enabled
ath0: [HT] 3 RX streams; 3 TX streams
ath0: AR9380 mac 448.3 RF5110 phy 2755.3
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000
Comment 30 Paul Armstrong 2018-07-04 11:34:42 UTC
Could we please have r306323 MFC'd into the 11 branch so that future 11 releases also have this update?
Comment 31 Kamil Choudhury 2018-07-04 12:47:21 UTC
At this point, your best hope is to wait for 12.0-RELEASE.
Comment 32 Chris Hutchinson 2018-07-07 06:05:56 UTC
What prevents this from being MFC'd to 11?

Its had *more* than enough time for review.

--Chris
Comment 33 commit-hook freebsd_committer 2019-01-27 14:28:03 UTC
A commit references this bug:

Author: avos
Date: Sun Jan 27 14:27:54 UTC 2019
New revision: 343493
URL: https://svnweb.freebsd.org/changeset/base/343493

Log:
  MFC r306323:
  [ath_hal] Add FCC6_FCCA regulatory domain (0x0014).

  PR:		194336
  Requested by:	Chris Hutchinson <portmaster@bsdforge.com>

Changes:
_U  stable/11/
  stable/11/sys/dev/ath/ath_hal/ah_internal.h
  stable/11/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h
  stable/11/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_freqbands.h
  stable/11/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_regmap.h