Date: Thu, 25 Aug 2011 13:37:18 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Garrett Cooper <yanegomi@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: if_ath - should it be compiled without ath_hal support? Message-ID: <CAJ-VmonnTxoWMbRE-PqtoDH1_16OpwK0Jw9hZ6WVkQjnr-JTfw@mail.gmail.com> In-Reply-To: <CAGH67wRz6X=ZU0AZFM1G-fo=NKHNVV7SD547KD-BBp4VOofDaw@mail.gmail.com> References: <CAGH67wRz6X=ZU0AZFM1G-fo=NKHNVV7SD547KD-BBp4VOofDaw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On 25 August 2011 12:49, Garrett Cooper <yanegomi@gmail.com> wrote: > =A0 =A0I ran into the panic shown below because it appears that some > array indexing went off into the weeds. I haven't seen this happen but > once though when running a buildworld last night using r225089 on > i386. > =A0 =A0This begs the question - is it wise to compile if_ath without > ath_hal support today? I've been doing this recently because ath_hal > isn't available under /sys/modules , and unless I unload the module, > things like suspend and resume don't work because if_ath doesn't > support suspend/resume yet). There are a lot of references to the > ath_hal APIs in if_ath.c now that don't have #ifdefs guarding them as > well which concern me.. Well, the ath_hal code should be built in as part of the ath module. ath needs ath_hal to speak to the MAC/baseband/radio. There's no need for #ifdef's to guard them as .. well, they're needed. I'd like to eventually split out the ath_hal again into a separate module and re-instate the separation between HAL and driver code (primarily to enforce cleaner code and more stable APIs.) If you're seeing issues like the above, chances are that you're seeing some corruption. Can you please print out the whole value of *rs (ie, all the fields of the ath_rx_status struct) so I can see how valid it is? Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonnTxoWMbRE-PqtoDH1_16OpwK0Jw9hZ6WVkQjnr-JTfw>