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
Card was bought in Canada if it matters. I can assist in testing patches etc.
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?
(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
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'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?
(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.
(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.
Updated 10.1-BETA and 10.1-RC versioned bugs to 10.1-STABLE.
Is this still an issue?
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
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
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'
sorry, keep pestering me until I figure out which country code to put this NIC in. :)
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
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
Created attachment 165875 [details] Add a regulatory domain for Canada This should be more appropriate fix.
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.
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
(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.
(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.
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.
(In reply to Greg Becker from comment #12) I have the same tl-wdn4800 card. Greg how do I install your fix?
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
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
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 :(
Hi! Try r306323 ! -a
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!
r306323 works! Unfortunately, 10 months after commit, it hasn't made it into any production release.
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
Could we please have r306323 MFC'd into the 11 branch so that future 11 releases also have this update?
At this point, your best hope is to wait for 12.0-RELEASE.
What prevents this from being MFC'd to 11? Its had *more* than enough time for review. --Chris
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