> > Hmm, I've seen the rate_control one before, and there's a guy
> > with ath5k who can reproduce it easily. Looks like minstrel
> > somehow gets confused about the rate table and eventually tries
> > to use -1 as a valid rate index. Neither I nor Felix could come
> > up with a logical explanation, though (I am completely lost in
> > the RC code, so that's not saying much for me).
> >
> > He is using ad-hoc too - but I use adhoc on a daily basis and
> > haven't seen it myself.
>
> Today I saw something similar with stlc45xx and wireless-testing:
>
> [11723.959442] kernel BUG at net/mac80211/rate.c:239!
>
> And the BUG_ON() is this:
>
> /*
> * try to enforce the maximum rate the user wanted
> */
> if (sdata->max_ratectrl_rateidx > -1)
> for (i = 0; i < IEEE80211_TX_MAX_RATES; i++) {
> if (info->control.rates[i].flags & IEEE80211_TX_RC_MCS)
> continue;
> info->control.rates[i].idx =
> min_t(s8, info->control.rates[i].idx,
> sdata->max_ratectrl_rateidx);
> }
>
> BUG_ON(info->control.rates[0].idx < 0);
> }
I think I'm in favour of "downgrading" that to a WARN_ON, like this:
if (WARN_ON(...))
info->control.rates[0].idx = rate_lowest()
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
