On Thu, 2016-01-28 at 11:01 -0800, Linus Torvalds wrote:
>
> I used to have the basic original UniFi UAP. I've replaced them with
> the newer "AC Lite" version:
>
> https://www.ubnt.com/unifi/unifi-ap-ac-lite/
>
> so it's a fairly big jump from a 2.4GHz-only network to a dual-band
> one.
>
> The old 2.4GHz-only AP's showed the problem with minstrel-ht
> incorrectly starting off at the highest rate (on a totally different
> machine). So the Unifi AP's have shown problems in the kernel
> wireless before, but so far it's always been the fault of the kernel
> wireless, not the AP.
Yeah; I wasn't trying to blame it on this change, I was just trying to
understand the change in the environment. Seems likely that it's simply
the switch to 5 GHz, which is strange, I'd have thought that even that
rtlwifi driver would've been tested with that :)
> > Could you print out the entire table there when the warning
> > happens?
>
> This is the best I can come up with: printing out the index, and the
> rate and bitrate tables:
>
> rates[i].idx (9) >= sband->n_bitrates (8)
> Rates:
> 0: idx 9 count 1 flags a0
> 1: idx 8 count 1 flags a0
> 2: idx 7 count 2 flags a0
> 3: idx 6 count 3 flags a0
Yeah, perfect. See, this is already evidently not making any sense:
flags a0 is
IEEE80211_TX_RC_40_MHZ_WIDTH | IEEE80211_TX_RC_SHORT_GI
both of those options *require* IEEE80211_TX_RC_MCS or
IEEE80211_TX_RC_VHT_MCS as well, so the flags really should be a8 or
1a0.
> Bitrates:
> 0: flags 00000002 bitrate 60 (hw: 0004 0000)
> 1: flags 00000000 bitrate 90 (hw: 0005 0000)
> 2: flags 00000002 bitrate 120 (hw: 0006 0000)
> 3: flags 00000000 bitrate 180 (hw: 0007 0000)
> 4: flags 00000002 bitrate 240 (hw: 0008 0000)
> 5: flags 00000000 bitrate 360 (hw: 0009 0000)
> 6: flags 00000000 bitrate 480 (hw: 000a 0000)
> 7: flags 00000000 bitrate 540 (hw: 000b 0000)
>
> So it's the very first rate that has index 9, but the bitrate table
> only goes from 0-7.
>
> So I suspect that once the first index has been marked invalid, it
> now will never even look at the later indices, so it has no transmit
> rates at all. Or something.
Indeed.
> That bitrate table does seem to match:
>
> static struct ieee80211_rate rtl_ratetable_5g[] = {
>
> in drivers/net/wireless/realtek/rtlwifi/base.c
>
Yeah, it would, but it's irrelevant since the rate table isn't actually
used with MCS rates.
I'm not familiar with this code at all, but looking at it suggests that
perhaps the switch to 5 GHz wasn't at fault, but instead the switch to
VHT (802.11ac) - that's more plausible too, not testing with VHT seems
like something that could have happened for this driver.
And as I figured, the code in _rtl_rc_rate_set_series() is obviously
not handling VHT correctly: it has
if (sgi_20 || sgi_40 || sgi_80)
rate->flags |= IEEE80211_TX_RC_SHORT_GI;
if (sta && sta->ht_cap.ht_supported &&
((wireless_mode == WIRELESS_MODE_N_5G) ||
(wireless_mode == WIRELESS_MODE_N_24G)))
rate->flags |= IEEE80211_TX_RC_MCS;
but can never set IEEE80211_TX_RC_VHT_MCS. Seems like there should be
something like
if (sta && sta->ht_cap.vht_supported &&
(wireless_mode == WIRELESS_MODE_AC_5G ||
wireless_mode == WIRELESS_MODE_AC_24G ||
wireless_mode == WIRELESS_MODE_AC_ONLY))
rate->flags |= IEEE80211_TX_RC_VHT_MCS;
just after/before the above block.
But I'm not familiar with this code at all, so that may not really be
the right fix or even work.
johannes
