While poking around at some instability and poor performance seen in download
direction, I noticed that the rate-ctrl was probably set incorrectly in
the iwlwifi driver due to link_sta->rx_nss being zero when changing active link
to the secondary link (the one we didn't originally associate with).
After debugging, I found that the hack below will make this problem
go away. I sincerely doubt this is the correct approach, but I'm not
sure how it is all supposed to work in the first place.
And as a side note, even once this is fixed, download throughput still suffers
much of the time. AP may be buggy, it is hard to tell where the fault lies.
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index 4dc1def69548..b69d0eb250d6 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -39,6 +39,27 @@ void rate_control_rate_init(struct sta_info *sta)
ieee80211_sta_init_nss(&sta->deflink);
+ pr_info("rate: sta-init-nss called from rate-control-rate-init, nss: %d\n",
+ sta->deflink.pub->rx_nss);
+
+ {
+ int z;
+
+ for (z = 0; z<IEEE80211_MLD_MAX_NUM_LINKS; z++) {
+ struct link_sta_info *ls =
+ rcu_dereference_protected(sta->link[z],
+ lockdep_is_held(&local->hw.wiphy->mtx));
+ if (!ls)
+ continue;
+ if (ls == &sta->deflink)
+ continue;
+
+ pr_info("rate: rate-control-rate-init, setting other link rx_nss from: %d to %d link-id: %d\n",
+ ls->pub->rx_nss, sta->deflink.pub->rx_nss, z);
+ ls->pub->rx_nss = sta->deflink.pub->rx_nss;
+ }
+ }
+
if (!ref)
return;
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
