diff mbox

WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

Message ID 56AAC66C.1080800@lwfinger.net
State Awaiting Upstream, archived
Delegated to: David Miller
Headers show

Commit Message

Larry Finger Jan. 29, 2016, 1:54 a.m. UTC 
On 01/28/2016 05:01 PM, Linus Torvalds wrote:
> On Thu, Jan 28, 2016 at 2:12 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>>
>> Your best workaround may just be to ignore VHT for now - clearly it's
>> broken so using "just" HT (which is likely not that much of a penalty
>> anyway since you're apparently not using 80 MHz) will be much better.
>>
>> Go into
>>
>> _rtl_init_hw_vht_capab()
>>
>> and just remove or stub out the entire contents of that (or you could
>> just remove the "vht_supported=true" if you feel like it.)
>>
>> That should get it to HT only, which is likely tested and working
>> better.
>
> Bingo. That indeed gets me working wireless. It's not super-fast, but
> I don't think it ever has been..
>
> If somebody has a suggested patch to actually *fix* VHT on this
> chipset, that would obviously be better. And maybe it works on some
> other chipsets, but not on mine. I'll happily test patches now that
> the merge window is over and I have some time again (and I can also
> make my AP do 80MHz channels if that matters, although as Johannes
> noted it's not enabled by default).
>
> For the realtek driver people, here is what lspci says:
>
> 02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821AE
> 802.11ac PCIe Wireless Network Adapter
>      Subsystem: AzureWave Device 2161
>      Kernel driver in use: rtl8821ae
>
> (Numeric PCI ID: 10ec:8821, subsystem 1a3b:2161)
>
> Thanks,

Linus,

I have been running an RTL8821AE since kernel 3.18 without hitting this problem 
using a TRENDnet AC1750 dual-band AP. The UniFi may be doing something that the 
driver is not expecting.

There have also been some problems with the regdom in some models of these chips 
that I also fail to see. It appears that some vendors are not coding the EEPROM 
correctly. That should not affect your system.

Attached is a minimal patch that comments out the "vht_cap->vht_supported = 
true;" statement for both RTL8821AE and RTL8812AE in _rtl_init_hw_vht_capab(). 
Does that allow your system to work? The patch also logs some information 
regarding the channelplan and the country code. Please let me know the values 
for those.

I apparently missed a previous complaint about this issue. If you still have the 
reference, please send it to me.

Larry

Comments

Linus Torvalds Jan. 29, 2016, 4:19 a.m. UTC | #1 
On Thu, Jan 28, 2016 at 5:54 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
> I have been running an RTL8821AE since kernel 3.18 without hitting this
> problem using a TRENDnet AC1750 dual-band AP. The UniFi may be doing
> something that the driver is not expecting.

I've had issues with unifi ap's before, but to be honest, I've had
issues with lots of hotel and airport wifi too. I don't think the
Unifi APs are outside of the normal spectrum..

> Attached is a minimal patch that comments out the "vht_cap->vht_supported =
> true;" statement for both RTL8821AE and RTL8812AE in
> _rtl_init_hw_vht_capab(). Does that allow your system to work?

That works too, yes.

> The patch
> also logs some information regarding the channelplan and the country code.
> Please let me know the values for those.

  rtlwifi: **** channelplan 127
  rtlwifi: **** country code 13

> I apparently missed a previous complaint about this issue. If you still have
> the reference, please send it to me.

So googling for similar issues, I found

  https://bugzilla.redhat.com/show_bug.cgi?id=1168467
  https://bugzilla.redhat.com/show_bug.cgi?id=1293136

where that second one in particular looks very like my issue
("Association succeeds, and ARP/DHCP work, but no IP frames can be
transmitted").

In both cases you have to go into the dmesg attachment to see that its
rtlwifi in both cases).

And there's an ubuntuforum thread

  http://ubuntuforums.org/showthread.php?t=2226009&page=2

where it you follow the thing, it's an rtl chip on a PCI card, and it
has very similar "connected but no internet" behavior, along with the
"net/mac80211/rate.c:526" warning (different line numbers, different
kernel version, but it smells similar).

Or this one:

  http://forums.debian.net/viewtopic.php?f=5&t=111781

which is also rtl-wifi, and also has the "associated, connected, got
an IP, but no data, not even a ping" behavior. It also has the
warning, but it looks different in other ways (2.4GHz only and
actually says it's not doing HT/VHT).

So I don't know. The warning in net/mac80211/rate.c:does seem to be
associated with the realtek driver.

             Linus
Johannes Berg Jan. 29, 2016, 8:33 a.m. UTC | #2 
On Thu, 2016-01-28 at 19:54 -0600, Larry Finger wrote:
> 
> I have been running an RTL8821AE since kernel 3.18 without hitting
> this problem 
> using a TRENDnet AC1750 dual-band AP. The UniFi may be doing
> something that the 
> driver is not expecting.

Are you quite sure you're actually using VHT though, perhaps the AP
somehow turned it off? It seems unlikely that you could successfully
use it in any way given that RATE_INFO_FLAGS_VHT_MCS doesn't show up in
the driver or rate scaling at all.


johannes
Johannes Berg Jan. 29, 2016, 4:15 p.m. UTC | #3 
On Fri, 2016-01-29 at 10:12 -0600, Larry Finger wrote:
> 
> Upon further inspection, my log has the line "rtl8821ae 0000:02:00.0
> wlp2s0: disabling HT/VHT due to WEP/TKIP use". I need to fix that
> first.
> 
Likely TKIP; enable only WPA2 (CCMP) on the AP.

johannes
Larry Finger Jan. 29, 2016, 4:54 p.m. UTC | #4 
On 01/29/2016 10:15 AM, Johannes Berg wrote:
> On Fri, 2016-01-29 at 10:12 -0600, Larry Finger wrote:
>>
>> Upon further inspection, my log has the line "rtl8821ae 0000:02:00.0
>> wlp2s0: disabling HT/VHT due to WEP/TKIP use". I need to fix that
>> first.
>>
> Likely TKIP; enable only WPA2 (CCMP) on the AP.

I found and fixed it. The AP was using only 20 MHz channels, but now is 
configured for 20/40/80. That duplicates the warning for me and the lack of 
throughput even though it associates and authenticates.

Larry
diff mbox

Patch

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c b/drivers/net/wireless/realtek/rtlwifi/base.c
index 0517a4f..2464d41 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -248,7 +248,7 @@  static void _rtl_init_hw_vht_capab(struct ieee80211_hw *hw,
 	if (rtlhal->hw_type == HARDWARE_TYPE_RTL8812AE) {
 		u16 mcs_map;
 
-		vht_cap->vht_supported = true;
+		/* vht_cap->vht_supported = true; */
 		vht_cap->cap =
 			IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895 |
 			IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991 |
@@ -282,7 +282,7 @@  static void _rtl_init_hw_vht_capab(struct ieee80211_hw *hw,
 	} else if (rtlhal->hw_type == HARDWARE_TYPE_RTL8821AE) {
 		u16 mcs_map;
 
-		vht_cap->vht_supported = true;
+		/* vht_cap->vht_supported = true; */
 		vht_cap->cap =
 			IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895 |
 			IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991 |
diff --git a/drivers/net/wireless/realtek/rtlwifi/regd.c b/drivers/net/wireless/realtek/rtlwifi/regd.c
index 5be3411..38f464e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/regd.c
+++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
@@ -340,6 +340,7 @@  static int _rtl_reg_notifier_apply(struct wiphy *wiphy,
 static const struct ieee80211_regdomain *_rtl_regdomain_select(
 						struct rtl_regulatory *reg)
 {
+	pr_info("**** country code %d\n", reg->country_code);
 	switch (reg->country_code) {
 	case COUNTRY_CODE_FCC:
 		return &rtl_regdom_no_midband;
@@ -400,6 +401,7 @@  static struct country_code_to_enum_rd *_rtl_regd_find_country(u16 countrycode)
 
 static u8 channel_plan_to_country_code(u8 channelplan)
 {
+	pr_info("**** channelplan %d\n", channelplan);
 	switch (channelplan) {
 	case 0x20:
 	case 0x21: