On Thu, Feb 25, 2010 at 12:59:50PM -0500, Andrew Blaich wrote:
(top posting undone)
> The main file I focused on was net/mac80211/rc80211minstrel.c, but I
> have tried forcing retry values through the other portions of the
> code.
>
> I have tried setting the counts in the MRR array (ar[i].count) in the
> minstrel_get_rate function, but that hasn't appeared to work,
> additionally I tried limiting the max retry count. I have had luck in
> altering the rate used by changing the index value fed into ar[i].idx.
> Maybe my issue is with the MRR array.
Well, this should work. The ath5k side of this is ath5k_txbuf_setup:
ret = ah->ah_setup_tx_desc(ah, ds, pktlen,
ieee80211_get_hdrlen_from_skb(skb),
get_hw_packet_type(skb),
(sc->power_level * 2),
hw_rate,
info->control.rates[0].count, keyidx, ah->ah_tx_ant, flags,
cts_rate, duration);
info->control.rates[0] is the TX rate (which may be different
for e.g. rts/cts frames than the one from the rate controller),
and the mrr rates are set up just after that:
ah->ah_setup_mrr_tx_desc(ah, ds,
mrr_rate[0], mrr_tries[0],
mrr_rate[1], mrr_tries[1],
mrr_rate[2], mrr_tries[2]);
The .count field in the mac80211 rate struct is the number of
tries, not retries, to be precise.
> next entry in the MRR array ar[1].idx=-1 so as to not try any rate,
> and then the count to 0 does this disable the rest of the MRR array,
> or is it possible the hardware is populating the array with other
> values?
That should be the case due to memset and get_alt_retry_rate semantics,
but if you suspect a problem you can printk in the above spots.
If the hardware doesn't respect those, there is some bug somewhere.
(Also see hw->max_rate_tries in ath5k_pci_probe()).
--
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
