On Thu, 2016-01-28 at 14:04 -0800, Linus Torvalds wrote:
Well, it "makes a difference" in the sense that the warning goes
away.
But it doesn't make things work. In fact, it might be making things
worse.
Heh, ok.
Because with that patch, the wireless still authenticates and
associates, but then it doesn't even get an IP address, so now even
dhcp doesn't work. Of course, I was surprised that it worked last
time, and I'm not 100% sure it did work consistently. I'll re-test
without the patch, just to make sure, but it doesn't really seem to
improve on anything.
It makes some sense, here's some speculation:
VHT rates are MCS 0-9. If the rate scaling decides to use only VHT
MCSes with a VHT-capable peer, then it stands to reason it might still
start at 0, but forget to set the VHT_MCS flag, so it would really use
rate index 0 from the table, which is 6 MBps. Then, it would see that
"working" (since it's not the right thing) and scale up until it hits
MCS 8 or 9, which is no longer a valid rate (those are only 0-7).
Since the suggested changes make it worse, we can assume that this is
not the only place where VHT is simply completely broken, and fixing
VHT here will instead uncover a bug elsewhere, that was previously not
happening because we never got to real VHT rates.
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.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 28, 2016 at 2:12 PM, Johannes Berg
[off-list ref] 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
On 01/28/2016 05:01 PM, Linus Torvalds wrote:
On Thu, Jan 28, 2016 at 2:12 PM, Johannes Berg
[off-list ref] wrote:
quoted
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