Date: Fri, 22 Mar 2013 08:55:03 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Mark Austin <ganthore@gmail.com> Cc: freebsd-wireless@freebsd.org Subject: Re: AR9300 Message-ID: <CAJ-Vmo=Q=MvWLH6BhaU%2BhZx1zojDjrT-yu9Aop7wi%2B6=RiXuAA@mail.gmail.com> In-Reply-To: <CA%2BO-CVJNMz2m8Z7fampK_WBomVTx5-Bt-SMxZyuA1DpZPv9J0Q@mail.gmail.com> References: <CA%2BO-CVL6%2BJ3xCjBqoHqFNKqL=p-DBKrtC8s6fU4-gCRPsX9G0A@mail.gmail.com> <CAJ-VmonzehGhkQBSyny25U2ADHUcxJbd6yETZj%2B3zbPLXfF%2BqA@mail.gmail.com> <CA%2BO-CVLihWn_TA0_LOQfQ_3e5p3Ss5UKAvpO9=vSbGmVggp1PA@mail.gmail.com> <CAJ-Vmo=zGVbOZg8g3T6GRsPZpiPqC8Nix-pB9idmv1iy9dkxgg@mail.gmail.com> <CA%2BO-CVKwDgrT0X1xcRNtDMomF6EjMFdpKaf=wshWVAmg7mQfuQ@mail.gmail.com> <CAJ-VmonwHkWMWejSwj9THrf_GrhFCB4=LeMewtDga-iWRxwrvQ@mail.gmail.com> <CA%2BO-CV%2BOrXnzsvJLGA3=X-usWzPWGVEQ59OXW2e2d9BzRifnaw@mail.gmail.com> <CAJ-VmomVBpnQhaJhWfq5sSh_Yjd98B6gK=xnmOwaOLWABOdrGA@mail.gmail.com> <CA%2BO-CVLCiSbz0NyT9SP%2B7k7EUqJFd7igU=DWpmgvTjWrcJwo4w@mail.gmail.com> <CAJ-Vmon=Duzvgw6wD%2B_fiAYW97%2BbQfuVrq_mwMCENR36X%2Bd3Yg@mail.gmail.com> <CA%2BO-CVKuUxf8nOoF3x%2B-KQD6OSBPGySdVHX6sE3d9f1ca4T6WQ@mail.gmail.com> <CAJ-VmoktdZ0iwXhrpb3k4Kr5WO3_iud=DcHj=dvcrsu-=2sSGQ@mail.gmail.com> <CA%2BO-CVJYgGPM4CwJBqjvd1RjWGnEELH%2ByAFv3a%2BPLT47T1pRDw@mail.gmail.com> <CA%2BO-CVK069mE5rzKqxEJ_%2BehxwP09u-DJ0EQCF_3LDbeqqkfhQ@mail.gmail.com> <CAJ-Vmok6faNaCwgqwhO2%2Bf7Uqwgg95VzAzQH8Egz6THVDd1dGA@mail.gmail.com> <CA%2BO-CVJNMz2m8Z7fampK_WBomVTx5-Bt-SMxZyuA1DpZPv9J0Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <ganthore@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=Q=MvWLH6BhaU%2BhZx1zojDjrT-yu9Aop7wi%2B6=RiXuAA>