netdev - Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Jan 2016 19:54:52 -0600
From:	Larry Finger <Larry.Finger@...inger.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Johannes Berg <johannes@...solutions.net>
Cc:	Chaoming Li <chaoming_li@...lsil.com.cn>,
	Kalle Valo <kvalo@...eaurora.org>,
	David Miller <davem@...emloft.net>,
	Linux Wireless List <linux-wireless@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates
 [mac80211]

On 01/28/2016 05:01 PM, Linus Torvalds wrote:
> On Thu, Jan 28, 2016 at 2:12 PM, Johannes Berg
> <johannes@...solutions.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



View attachment "rtl8821ae_test.patch" of type "text/x-patch" (1724 bytes)