Hi, I'm cc'ing -wireless now, as this is actually good to have public.
Ok, can you post (or re-post) the ath device line from 'pciconf -lv' ? I'd like to see which device it is. And, inline: On 22 March 2013 08:44, Mark Austin <ganth...@gmail.com> wrote: > Hey Adrian, > > Okay. I was able to successfully build the kernel. I installed and loaded > the kernel today and was able to kldload the if_ath_pci module. > > ath0 is not exposed to ifconfig as a device. > > The module gives the following kernel messages: > > Mar 22 15:37:12 asher kernel: ath0: <Atheros AR946x/AR948x> mem > 0xc2400000-0xc247ffff irq 17 at device 0.0 on pci3 > Ok, so it probed fine. > Mar 22 15:37:12 asher kernel: ar9300_set_stub_functions: setting stub > functions > Mar 22 15:37:12 asher kernel: ar9300_set_stub_functions: setting stub > functions > Mar 22 15:37:12 asher kernel: ar9300_attach: calling ar9300_hw_attach > Mar 22 15:37:12 asher kernel: ar9300_hw_attach: calling > ar9300_eeprom_attach > Mar 22 15:37:12 asher kernel: ar9300_flash_map: unimplemented for now > Mar 22 15:37:12 asher kernel: Restoring Cal data from DRAM > Mar 22 15:37:12 asher kernel: Restoring Cal data from EEPROM > Mar 22 15:37:12 asher kernel: Restoring Cal data from Flash > Mar 22 15:37:12 asher kernel: Restoring Cal data from Flash > Mar 22 15:37:12 asher kernel: Restoring Cal data from OTP > Mar 22 15:37:12 asher kernel: ar9300_hw_attach: ar9300_eeprom_attach > returned 0 > Mar 22 15:37:12 asher kernel: ar9300_fill_capability_info: (MCI) MCI > support = 1 > Ok, so MCI is available but we don't enable it by default. Well, I hope we don't enable it in the HAL by default as I haven't implemented MCI yet. > Mar 22 15:37:12 asher kernel: ath0: RX status length: 48 > Mar 22 15:37:12 asher kernel: ath0: RX buffer size: 4096 > Mar 22 15:37:12 asher kernel: ath0: TX descriptor length: 128 > Mar 22 15:37:12 asher kernel: ath0: TX status length: 36 > Mar 22 15:37:12 asher kernel: ath0: TX buffers per descriptor: 4 > Mar 22 15:37:12 asher kernel: ar9300_freebsd_setup_x_tx_desc: called, > 0x0/0, 0x0/0, 0x0/0 > Mar 22 15:37:12 asher kernel: ath0: ath_getchannels: unable to collect > channel list from hal, status 12 > Mar 22 15:37:12 asher kernel: device_attach: ath0 attach returned 22 > Ok, HAL status 12 here is HAL_EINVAL. That's a call to ath_hal_init_channels() that's failing. So I wonder if it's a regulatory domain database problem. I wonder what the EEPROM code is. It may be something really stupid like the default regulatory domain not being in the HAL database. Can you edit sys/dev/ath/ath_hal/ah_regdomain.c, and find ath_hal_init_channels(). Then before the call to getchannels, add this: ath_hal_printf(ah, "%s: cc=%d, regdmn=%d\n", __func__, (int) cc, (int) regDmn); Then just recompile/reinstall the modules, and reload if_ath.ko and then if_ath_pci.ko. I'd like to see _what_ the initial detected regulatory domain is. I bet it's erroring out there. Thanks, Adrian _______________________________________________ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
