Project: Add 8821/11au rtw88 in-kernel driver. Need testers... #133
Comments
|
I get a maximum of 130 Mbps transmit and 93 RX with iperf3. LibreSpeed gets 119 down and 113 up. |
|
The master branch now contains all of dubhater's changes for the RTW8821AU and RTW8812AU, and the driver works. I have not removed any of the other branches until the code is checked a bit more, but please test everything. The speeds are still on the low side, but that will come. |
|
Initital testing of rtw88 master: I ran iperf3 several times with my primary testing setup. Speed looks really good. Around 220 Mbps is about as fast as this chip can go if the out-of-kernel results over the last few years are good. The test above is on a DFS channel where there is no congestion. dmesg is clean. I'm impressed so far. Monitor mode frame injection test: Going in and out of monitor mode works well and things look like they should. The injection test above showed very good results. So far monitor mode looks good. I will do more detailed test on managed and monitor mode as able this week and I plan to test AP mode and I plan to rework the first message in this thread to provide instructions to those who can test/report as most will not be used to the instructions for getting this driver going, I am still looking for someone with a rtl8821au based adapter and someone with an old laptop with a rtl8821ce chip in it so we can test bluetooth. |
|
@morrownr rtw_8812au is not ready yet. I can see some RTL8821AE on Aliexpress, both M.2 and mini PCIe. |
Give me a chance to round up some testers that already have the chips. We can always go get one if we have to do so. This repo gets over 100 hits per day so there are a lot of users of this chip. I just need to work on getting them in here now that we have something for them to test. I'll work it. I'm impressed with this driver so far. We'll find problems but so far it is working well. My opinion after a few years of supporting out-of-kernel drivers for both the rtl8821au and rtl8821cu is that the au is simply a more reliable chip that causes users far fewer problems. |
|
I have a TP-Link Archer T2U PLUS [RTL8821AU]. I removed this kernel module using So far everything is working good. I am willing to help, but I don't have a lot of experience in this field. Are there any instructions to run the required tests? Just let me know. |
|
Hi @gmsanchez Thanks for testing.
Do you have any experience using any modes in addition to managed (client) mode? Please document your distro and version here and post the results of the following: $ uname -r Do you know of a way to test your speed? If so, do it. Post the results of: $ sudo dmesg | grep rtw Since you have an adapter with the version of the chip that has bluetooth support, can you verify that bluetooth is working correctly? Post the results of: $ lsusb If your adapter has an LED, does it blink? Lastly, just use it. See if anything goes wrong over the next few days. Keep us posted. |
I don't know how to test my speed.
I don't have any bluetooth device on my system.
I'll move the adapter to the front and check the LED status. In the meantime, the requested output of the commands is below: |
|
rtw88 master - rtw_8821au I am seeing the below during compilation. This is with Debian 12 and kernels 6.1 LTS and 6.6 LTS plus gcc 12.2. This not fatal but... |
|
The problem is that the code used max(a,b), whereas it should have been max_t(u32,a,b). It now compiles cleanly on openSUSE Tumbleweed and Debian 12. |
You can give the following site a try for basic speed testing: Most of us use iperf3 on our local lans for speed testing. Do you have a RasPi on your local lan or a wifi router that runs OpenWRT?
It looked like you might have a version of the chipset that includes bluetooth support so I was looking to see if the bluetooth in your adapter was working. Maybe you have a chip that is wifi only.
Let me think out loud here for a moment. I am trying to sort out why the above line is needed. What is it doing for us? Thanks for the info and we'll be waiting for additional reports. |
Awesome! Clean compile here. FYI: I'll be moving to AP mode testing soon. So far, managed and monitor modes look really good but my AP mode testing will take me to another distro and ARM64. |
|
Here is a very minor nitpick:
When I run iperf3, I am seeing Like I said, nitpick. I am having a difficult time finding any problems with managed and monitor modes. I am off to test AP mode. |
|
Do you see any WARNINGS in your logs like this "WARNING: CPU: 3 PID: 36 at net/mac80211/rx.c"? Your CPU and PID will be different. That may be the source of your drops. I have a patch to silence the WARNINGS, but the drops are not fixed as the packets are malformed. What is the utility that produced the screenshot? I am not familiar with anything like it. |
|
@morrownr I'm using a Debian-based custom arm64/armhf distribution, and as such I can't build the rtw88 driver via @lwfinger's process (I didn't bother to try to address this further). Instead, I simply removed the original mainline (6.9-rc7) rtw88 driver source and replaced it completely with @lwfinger's version from his github. Now, when building this new version of rtw88 I am getting errors relating to the PCI driver module support or something (see errors below). My kernel configuration does not enable CONFIG_PCI, just in case this might be related. I haven't debugged the new in-kernel rtw88 build process any further. I'm pointing this out just in case there is an oversight in this new rtw88 code for non-CONFIG_PCI and/or ARM builds (or something). As a comparison, the mainline 6.9-rc7 rtw88 driver builds completely fine - without any errors - so there does appear to be a regression in this new version of the driver source. In my kernel config I am only enabling the the 8821CU module, so it is kind of odd that the build is erroring out for driver sources that aren't even enabled: Build errors: |
My environment for testing has been updated from Kubuntu 23.10 to 24.04. I have been using GNOME instead of KDE both before and after the update. After confirming that the adapter was working in the GNOME session, I switched to the KDE session and started experiencing connection failures. From that point onwards, even after rebooting the machine and logging back into GNOME, the connection fails. I was able to connect successfully in both GNOME and KDE sessions after installing and rebooting with commit 530df1a4 (Revert "Allow 8821au, 8812au to enter IPS") from the master branch. However, the connection fails without this fix. I apologize for the change in the situation since my previous report and any inconvenience caused. |
|
@Jake-Grafton But joking aside. While writing this, I'm compiling 6.10-rc3 with an applied patch (which should fix monitor mode): Regards |
|
Some good news. The kernel bug has been fixed! Regards |
That is good news. Thanks for being persistent in your reporting. |
Please don't apologize. I am conducting an investigation. A question that has to be answered is whether it is a problem in the driver with all distros, with some distros or if it is not a problem in the driver but rather a problem in a distro. I'm digging pretty hard since I have not been able to duplicate the problem on Debian 12 (kernel 6.6) and Ubuntu 24.02 (kernel 6.8). I'm attempting to install Kubuntu 24.04 but I keep into problems. I will eventually make it happen.
I'm not going to refer to "Allow 8821au, 8812au to enter IPS" as a fix because what it does is turn off IPS, which we want. The reason you saw me to recommend to @dubhater to turn IPS back on is because I am the only one right now trying to track this down and we need to know if others are seeing a problem. We can tell you which 3 lines to comment out so that you can continue, if necessary.
I understand. From a bug investigators perspective, that complicates things. While Ubuntu and the flavors do a good job of upgrading from version to version, that is still an extremely complicated thing to do and some little detail could have gone haywire. It is a situation is nearly impossible for me to reproduce. I hate to ask but could you backup your important files and do a format c: type of clean Kubuntu 24.04 installation? Cheers |
|
Hi @morrownr ,
Thank you for the clarification. I understand that turning off IPS is a temporary measure to address the issue.
Thank you for your understanding. I'm happy to try a clean installation of Kubuntu 24.04, as you suggested. However, it might take me a month or even two to get that done. Downloading the large ISO file and installing the toolchain require a stable network connection, preferably wired. My machine is located quite far from the router, so I need to get a longer LAN cable and set everything up. Also, reinstalling the OS and all necessary software takes time and effort, and I want to make sure I can allocate enough time for it without rushing. I hope you understand. I'll keep you updated on my progress. Best regards, |
Yes, I understand this. How about you not worry about installing new for now. I won't go into detail (it is actually kind of funny) but getting a clean installation of Kubuntu has proven to be a challenge here this week. What I finally did was install kubuntu-desktop on my clean Ubuntu installation. So far I have not been able to duplicate the problem while using the KDE desktop. It is proving to be an allusive problem. I think it is time to turn IPS back on so as to get wider testing. Thanks for your testing and hope you can continue as you are able. |
|
Im a bit busy with life atm, but remember that Neojou (Senior Realtek developer) left me this; |
|
@morrownr I turned on IPS again. I will let y'all know when the code is ready for an audit. Don't look at the IQ calibration yet. :) Untangling 8821au from 8812au is more work. I'm not too keen on it. Upstreaming the firmware is easy. You make a patch for the linux-firmware repository and email it to Ping-Ke, who will add signed-off-by and forward it to the linux-firmware mailing list. I've been working on the Bluetooth coexistence. I'll move on to the RTL8812AU soon. |
Thanks. I think that is the best way forward with this issue.
When you are ready, it might help if you list the files that have been added and modified for 8821a support so we are on the same sheet of music. I don't have a black belt in wireless coding but can find some things. Maybe @kimocoder could find a little time around the time you ask. I like to have others going over my work as it can be hard to see your own issues.
I get that and I was not actually pushing for a full separation at this time. I was really more looking to see if you could get things in configuration where 8821a could be upstreamed without 8812a so that 8821a could start working its way through review while we mostly switch over to working 8812au. I'm sure some 8812a code could be left in for now... or at least warn Ping-Ke that 8812a is coming soon so that he understands what the plan is. You caught me once already when I modified a link in the file that I was working on that includes the vid/pids for 8812au. I was unaware of your plan but it became obvious when I broke the driver. :-)
I'll add this to my to-do list. I just happened to think that I don't remember the location of the firmware in the vendor driver. Point me in the right direction if you don't mind.
How is that going? And that reminds me that we still have not found anyone using the 8821ae driver. I think you said you saw where a 8821ae card is available that would work in something you have. Do we need to need at a donation drive to fund that? ... or should ae support be removed due to apparent lack of interest? |
|
The firmware is already here: https://github.com/lwfinger/rtw88/blob/master/rtw8812a_fw.bin The bluetooth coexistence in the 2.4 GHz band is disappointing. The official driver can do 3/5 Mbps while using the bluetooth headphones. rtw88 is just a little better. I can't watch a 1080p Youtube video like this. I'm not 100% sure, but I'm optimistic that my laptop's BIOS would accept other wifi cards. Maybe later... |
|
And be aware that Neojou (Senior Realtek engineer) left rtw88-usb behind, before he changed work 👍 I'll get more time soon, too much work on my private still 🤌 |
|
Not sure if you are still looking for testers, but I got an RTL8821AU adapter. $ lsusb
TP-Link Archer T2U PLUS [RTL8821AU]$ uname -r
6.9.4-200.fc40.x86_64I have had issues with aircrack repo since upgrading to kernel 6.8.10, after installing the rtw88 driver I haven't noticed any issues. git clone https://github.com/lwfinger/rtw88.git
cd rtw88
make
sudo make install
sudo reboot$ sudo dmesg | grep rtw
[ 19.530755] rtw_core: loading out-of-tree module taints kernel.
[ 19.530759] rtw_core: module verification failed: signature and/or required key missing - tainting kernel
[ 19.585413] rtw_8821au 3-1:1.0: Firmware version 42.4.0, H2C version 0
[ 19.849693] usbcore: registered new interface driver rtw_8821au
[ 19.878718] rtw_8821au 3-1:1.0 wlp45s0f3u1: renamed from wlan0
[ 29.383046] rtw_8821au 3-1:1.0: MAC has not been powered on yet
[ 31.938425] rtw_8821au 3-1:1.0: rtw8821a_power_off: bailing because RTW_FLAG_POWERON
[ 31.939328] rtw_8821au 3-1:1.0: MAC has not been powered on yet
[ 34.532932] rtw_8821au 3-1:1.0: MAC has not been powered on yet
[ 40.549185] rtw_8821au 3-1:1.0: rtw8821a_power_off: bailing because RTW_FLAG_POWERON
[ 40.549812] rtw_8821au 3-1:1.0: MAC has not been powered on yet
[ 43.081316] rtw_8821au 3-1:1.0: MAC has not been powered on yetHappy to help any way I can, just give me ping. Thanks for the great driver 🙏 |
|
Hi @souperk
We need testers for this project now and hopefully also for future projects so if you have adapters based on the 8812au or 8814au, hopefully we will be testing those drivers at some point this year.
Starting at some point with kernel 6.8, there are some things that are broken in the wireless stack regarding monitor mode. @ZerBea probably has the latest status on that. Those will go away once the driver is in the mainline kernel. These are operations normal. I'm still pondering what this line is doing for us. Seems to not be any help. It would be helpful if it was telling us why something is wrong but we see it when things appear to be working well. This is a new one for me. That begs the question: if everything is working, why are we seeing this? If you are able to test IBSS, that would be great. We've had reports on all supported with the exception of IBSS. Of course, maybe we should consider shutting down IBSS as it does not appear to have any users these days. Thanks for testing and reporting. |
Yes, I was thinking of checking to make sure the one we have in rtw88 is the version in the latest 8812au repo but I seem to remember @lwfinger extracting it from there so we should be good except for getting it to Ping-Ke. I'll work on that.
You are trying to watch 1080p streaming videos with it? I can't say that this has come up in my world but that seems like a stretch for bluetooth technology. It is a little frequency hopping technology that runs around the 2.4 GHz band. I would not expect much bandwidth but then I have never pushed it or really, for that matter, have never used bluetooth that much. Have you done better with later versions of bluetooth?
I've been doing some looking around to see what I can find regarding 2 issue we face. The results: Should we support 8821ae? My answer at this point is no. Why? I'm not finding any strong evidence that the 8821ae was ever used much. Intel truly dominated wireless cards during the prime time that laptop makers would have been including the little cards in laptops so very small market share is probably all there would have been. When people retire laptops, they don't generally open them up and take the wireless card to save for future use and most laptops that would have had a 8821ae chip are probably retired by now. The cards might, or probably would not be something that would work in modern slots anyway. I say any effort to support 8821ae is a waste of time. I propose cleaning out any source and files supporting 8821ae and drop the support. It won't be missed. Should we support IBSS? My answer at this point is no. I've had Realtek out-of-kernel drivers here at this site for several years and I can count how many times it has come up on 2 fingers. There does not appear to be any interest in it. In fact, Mediatek's WiFi 6 and 7 in-kernel usb drivers do not support it and I have seen exactly zero users asking for it. So, same as above, my recommendation is to turn off the capability and clean out any code that is specific to this chip. I don't bring my ego to this forum so please, tell me what is wrong with the above recommendations if you disagree. I am looking at this and other things with an eye toward being as efficient as possible with the resources we have available. There is also the issue of future supportability for both issues. |
|
@morrownr , starting with kernel 6.9.5 mac80211 has been fixed an I closed the report: |
|
@morrownr rtw8812a_fw.bin came from your 8812au-20210820. I don't know if it's because of the newer bluetooth standard (5.0 versus 4.0) or because they put more effort into the driver, but the internal RTL8822CE works much better than RTL8821AU when I use the bluetooth headphones. I agree about RTL8821AE. It's already supported by rtlwifi, so we don't need to put effort into accommodating it in rtw88. As for IBSS mode, it probably works if AP mode works. I say we leave it alone because removing it is an extra patch to send upstream. All the logic is in the common parts of rtw88. |
AP mode is working very well. I gave it an extended test and could find nothing other than lack of DFS support but that is the norm with usb adapters so I'll mark IBSS off my list of things to worry about.
That means
Maybe someone with more experience with bluetooth will come along and shine some light on this.
Okay, good. Is there anything that you want me working on? |
|
Hi there, I just bought myself a Built https://github.com/lwfinger/rtw88 (it built cleanly with no warnings), the compilation flags were apparently: After Seeing this in the logs: I'm not seeing anything bluetooth-related appear, but perhaps I don't know where to look for it. Please let me know what sort of tests / checks / benchmarks I can run that would be useful to you. |
|
Hi @bugaevc
I just took a stroll by TP-Link's site to read what they say about the TP-Link Archer T2U PLUS. There was no mention of bluetooth capability. I also did some quick and dirty searching and I think this adapter is wifi only which means it is actually using the RTL8811AU chip. This driver works for both chips.
Mostly just use it and see if anything undesirable comes up. If you want to do something that may take some of your time, we could certainly use a test report on IBSS mode. Thanks for testing. I curious as to your thoughts on the below lines in the log: kernel: rtw_8821au 2-1.3:1.0: rtw8821a_power_off: bailing because RTW_FLAG_POWERON |
|
I pushed some more stuff:
|
|
Thank you so much for your hard work.
I will create a new Project issue in the 8812au repo so as to gain testers and keep 8812au stuff in one place: Title: Project: Add 8812au rtw88 in-kernel driver. Need testers... Should I also add a Project issue to the 88x2bu repo so as to attract testers that have the 8822/12bu? |
I'm not sure. Maybe rtw8821a_power_off is being called twice in a row somehow? I added some debugging messages which may help us understand what is going on. Anyone who saw "bailing because RTW_FLAG_POWERON" should load rtw_core with the parameter "debug_mask=0x80000000" to enable the new messages.
Yes, it would be good to have more people test the USB 3 support. |
Greetings to anyone that reads this message.
This Issue is where we coordinate and take bug report for the new 8821a in-kernel driver.
An effort is underway to add support for the rtl8821/11au chipset to the rtw88 in-kernel driver series. The driver is available for testing at the following repo:
https://github.com/lwfinger/rtw88
Remember to first remove the out-of-kernel driver in this repo or whatever repo you may have installed. You can run the following to remove it if using this repo:
$ sudo sh remove-driver.sh
It is important to follow the instructions in the README at the repo with the new test driver. You may not be familiar with rtw88 in the kernel but even if you are, there are some necessary mods that you need to know about. The rtw88 that has this new driver is more advanced than the rtw88 in stable kernels as it follows wireless-next and is used to work on and develop new drivers.
We welcome you to test and report on this new driver. Your testing will help us get this new driver in the Linux kernel sooner and in better shape. We do have specific needs. The most immediate need is to find users that have adapters that have bluetooth support (rtl8821au chip). The current developers only have adapters that have rtl8811au chips so we need help. We also need testers with old laptps that have the rtl8821ae chip.
If you are aware of anyone who is familiar with mac80211 drivers, please invite them as more eyes on the code is a good thing. Your ideas are most welcome. We can do this.
@morrownr
Status report:
A possible outstanding bug has to do with idle power savings (IPS). This bug is under investigation.
Managed mode (client) appears to be in good shape. There some reports of slow performance on some ARM platforms, This is being investigated.
Monitor mode appears to be in good shape but Active Monitor mode is not supported. Monitor mode needs more testing.
AP mode is in good shape but AP Mode DFS channels are not supported (this common on usb wifi adapters). This is an issue that needs to be investigated but should not slow down the upstreaming of this driver.
P2P mode is in good shape.
IBSS mode has not been tested yet. Please test and report.
Overall: the driver appears to be in good shape but we need a lot of testing to take place. Please test and report your results.
The text was updated successfully, but these errors were encountered: