Re: if_ath - should it be compiled without ath_hal support?

Hi,

On 25 August 2011 12:49, Garrett Cooper <yanegomi_at_gmail.com> wrote:
>    I 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.
>    This 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