Project: Improve the 8822bu rtw88 in-kernel driver. Need testers... #224
Comments
|
Hello @morrownr , I wanted to provide an update on my ongoing efforts to set up a stable wifi-driver on my device. Steps Taken and Findings:
Setup Details: Hardware: I use a SOM board with interchangeable CPUs, and the 8822cu is permanently connected via USB 2.0. Hardware Specification (from lshw):
Steps to Ensure Driver Functionality:
Thank you in advance for your support! Best regards, |
|
Thanks for the report. It appears that the rtw 8822CU driver is not in good shape at all. The out-of-kernel driver you pointed me to is a very old driver that is not being maintained so no wonder it does not work on anything near a modern kernel. If your needs include something that works well in the short term, you may want to take a look at the Plug and Play List on the Main Menu: https://github.com/morrownr/USB-WiFi This message is in the Project Issue in the 882xBU repo. I am also going to channel users with 8822cu based adapters into here as I do not have a repo for the 8822cu... and I don't have an adapter. That the rtw 8822CU driver is not in good shape should come as no surprise. What are your thoughts on the 8822cu? |
|
I think 8822cu, 8822bu, and 8821cu have a common problem. They use a common code base (the "halmac" stuff in the official driver) so it makes sense. @ADV-LUT Unless you want to dive into the code and find what is missing from rtw88, there is nothing you can do to make it work better. |
|
Thanks for the quick response. I was just looking for suitable adapters for the 8822cu and found this one: https://www.top-electronicsusa.com/lm842-8426-us-wifi-80211ac-bluetooth-50-2t2r-usb-combi-adapter-with-sma-antenna-connector-p-17843.html If that's an option, we would order the adapter and send it to you. |
|
@morrownr The original driver which is no more supported can be found here. Issue Report: TP-Link Archer T2U USB Wi-Fi Adapter Driver Installation on Kernel 6.8.0-36-genericKernel Versionuname -r
# Output: 6.8.0-36-genericSummaryWe attempted to install the driver for the TP-Link Archer T2U USB Wi-Fi adapter on a system running kernel version Steps Taken1. Initial SetupWe updated the system and installed the required packages: sudo apt update
sudo apt install -y dkms build-essential libelf-dev linux-headers-$(uname -r) git2. Clean Up Previous InstallationsRemoved any existing DKMS modules and cleaned up the build directory: sudo dkms remove realtek-rtl88xxau/5.6.4.2~20240509 --all
cd ~/rtl8812au
sudo make clean3. Clone a Reliable Community Driver RepositoryCloned a known reliable driver repository: cd ~
git clone https://github.com/morrownr/88x2bu.git
cd 88x2bu4. Build and Install the Driver Using DKMSAdded, built, and installed the DKMS module: sudo dkms add .
sudo dkms build 88x2bu/5.8.7
sudo dkms install 88x2bu/5.8.75. Load the DriverAttempted to load the driver: sudo modprobe 88x2bu6. Check for ErrorsChecked sudo dmesg | tail
# Encountered the following errors:
# [ 3698.455187] 88XXau: Unknown symbol cfg80211_michael_mic_failure (err -2)
# [ 3698.455218] 88XXau: Unknown symbol cfg80211_external_auth_request (err -2)
# [ 3698.455235] 88XXau: Unknown symbol cfg80211_connect_done (err -2)
# [ 3698.455306] 88XXau: Unknown symbol wiphy_register (err -2)
# [ 3698.455321] 88XXau: Unknown symbol wiphy_free (err -2)
# [ 3698.455354] 88XXau: Unknown symbol ieee80211_channel_to_freq_khz (err -2)
# [ 3698.455388] 88XXau: Unknown symbol cfg80211_ch_switch_started_notify (err -2)7. Verify the Modules are LoadedEnsured the necessary wireless stack modules ( sudo modprobe cfg80211
sudo modprobe mac80211
lsmod | grep cfg80211
lsmod | grep mac80211
# Output:
# cfg80211 1339392 1 mac80211
# mac80211 1728512 0
# libarc4 12288 1 mac80211
# cfg80211 1339392 1 mac802118. Attempt to Load the Driver AgainTried loading the driver again: sudo modprobe 88x2bu9. Check for Errors AgainChecked sudo dmesg | tail
# Same errors persisted:
# [ 3698.455187] 88XXau: Unknown symbol cfg80211_michael_mic_failure (err -2)
# [ 3698.455218] 88XXau: Unknown symbol cfg80211_external_auth_request (err -2)
# [ 3698.455235] 88XXau: Unknown symbol cfg80211_connect_done (err -2)
# [ 3698.455306] 88XXau: Unknown symbol wiphy_register (err -2)
# [ 3698.455321] 88XXau: Unknown symbol wiphy_free (err -2)
# [ 3698.455354] 88XXau: Unknown symbol ieee80211_channel_to_freq_khz (err -2)
# [ 3698.455388] 88XXau: Unknown symbol cfg80211_ch_switch_started_notify (err -2)ConclusionDespite following all the steps to install and load the driver, the module failed to load due to missing symbols related to Logs and Additional Information
We hope this detailed report helps in diagnosing and resolving the issue with the TP-Link Archer T2U USB Wi-Fi adapter driver on newer kernel versions. If you need any additional information, please feel free to reach out. |
|
Hi @Khnaz35 I do see some problems but this issue is for reports on the work to improve the rtw88 support for rtw88_8822bu/cu. So please keep that in mind and if more than one message is required, I will probably ask you to establish the bug report in another location.
I think that adapter uses a rtl8811au chip but lets check: $ lsusb Post the result. Tell us what distro you are using. I could not put enough puzzle pieces together to figure it out.
Well, that is not a 88x2bu driver you are removing so the mystery of what chip is in your adapter continues.
That is the driver in this repo. It supports the 88x2bu chips.
I can appreciate that you know how to manually use dkms but you did not read the README did you? The installations steps in the README are such that it makes it hard to mess up installing this or any out-of-kernel driver at this site. The driver version in this repo is not 5.8.7 and that is where things went south. Let's start with the requested info so we can figure out what chip you have and what distro you are using. My best guess is that you adapter uses a rtl8811au chip. Let's figure out the chip and go from there. |
|
@morrownr Thanks for getting back much appreciated. Here are results Tell us what distro you are using. |
That ID means your adapter is based on the rtl8821/11au chip so this repo is the wrong driver.
You need to uninstall that driver. The correct driver repo is: https://github.com/morrownr/8821au-20210708 Just follow the installation steps in the README. There is an alternate if you are interested in testing a driver for this adapter that is in testing and should go into the Linux kernel soon: Read and follow the first message in that thread. I'll see you over in the 8821au repo. |
|
Sorry for the delay. Health issues have slowed me greatly lately.
While I appreciate the offer, I don't have a good source for new Realtek vendor drivers for that chip. I have relationships with some adapter makers/retails that will pull and send new code to me at times but none of them make or sell adapters with the rtl8822cu chip. That chip came along very late cycle for WiFi 5 class chips and I could not see any real advantage over the rtl8822bu chip. The rtl8822cu could lose support in the long term due to having a small userbase so it is not a chip that I recommend to users. Not to mention that Mediatek has blown pasted Realtek in driver quality and support. My recommendation is to not plan future usb wifi adapter and module purchases unless you check your options for Mediatek chip based devices. What I do recommend can be found in menu items 1, 2 and 3 on the site Main Menu: |
|
@morrownr Unfortunately I can't just use a different adapter because the chip is soldered onto the motherboard. This means I'm currently forced to get this chip working. Thanks for the very detailed list, in the future we will take this into account when making our selection. What other options do you see if I absolutely have to get the 8822cu working? |
There are options but first I need to know what chip you have. It would be very unusual for a board maker to solder a usb chip onto the mainboard. Let's investigate. Run the following commands and post the results: $ lsusb
We can talk about this but first let's figure out exactly what you have. |
Bus 002 Device 002: ID 0424:7206 Microchip Technology, Inc. (formerly SMSC) USB7206 Smart Hub Bus 001 Device 007: ID 0bda:c82c Realtek Semiconductor Corp. 802.11ac NICBus 001 Device 005: ID 2c7c:0125 Quectel Wireless Solutions Co., Ltd. EC25 LTE modem
0004:00:00.0 PCI bridge: NVIDIA Corporation Device 229c (rev a1) |
|
That is a usb chip ID using the rtl8822cu chip. Okay, are you still using kernel 5.15? There is a situation with more modern kernels that you need to be aware of. The ID of your device was inadvertently put in the modern Linux kernel (6.1+) for two different drivers which causes a conflict. I recently sent a patch to resolve this issue. That should not be an issue if you are using kernel 5.15. Could you post the results of: $ lsmod What modes are you running? AP, managed, other? |
|
Yes, I'm still using kernel version 5.15 I just re-flashed my board to test the latest version of the driver and now I can no longer install rtw88. But I was able to install the driver successfully before. Now I get the following error messages:
Here is my output for $lsmod:
I had previously gained the following insights: Usage as a Normal WiFi Connection:
Usage as a Hotspot:
|
|
I got the driver running again. To do this, I added "EXTRA_CFLAGS += -std=gnu99" to the Makefile. Here is the current $lsmod:
I have tested the functions of a normal WLAN connection and an AP again with the latest version. I can share the following findings:
lshw shows the following:
|
|
Nevermind for now. There is nothing to test because it's not actually working. |
|
I had just started testing and could not even get an interface. Was just starting to try to figure out why. I'll standby. |
|
That's not supposed to happen. It should still work like before, just with no Rx aggregation. |
Famous last words. Sorry, had to recognize the humor in the situation. |
|
Indeed. I don't know what happened. You may have to bisect it. The RX aggregation is ready for testing now. |
Just finished test rtw_8822bu with the latest: Your efforts to increase managed mode performance have worked. That is outstanding for an AC1200 class wifi adapter. I did extra testing on usb: I tested in usb2 ports and usb3 ports. Not seeing any problems. I'll look around the log and check back in. Are we still pending Realtek help to fix something that causes problems with AP mode? |
|
This finishes up my current testing on rtw_8822 in managed mode: Clean log. Speed is excellent. Super stable. I can support you upstreaming the needed patches. Tests accomplished on Debian 12 with kernel 6.9. |
|
I've continued testing rtw_8822bu. I ran into the following which is a little concerning: |
|
As I continue testing my rtl8812bu based adapter with rtw8822bu, I ran into some noise in the log after leaving the system idle while being away for around an hour. When I came back, the connection was down and the following was in the log: |
|
That's interesting. Can I see the unfiltered dmesg, please? |
|
@dubhater
When I reconnect, the following error message appears again in the dmesg and nothing works: |
|
@ADV-LUT Did it ever work better? Can you try an older commit, like 1086d09? |
|
AP mode improved a lot with the latest commit lwfinger/rtw88@4a1ee64. But I still observe these errors: |
|
See my response regarding slow bit rate in mainline and downstream driver : |
|
@ADV-LUT I got the LM842 today, thank you! Bad news, though: it's working perfectly so far with my Arch Linux system. Tomorrow I will try with Ubuntu 22.04. |
|
Ubuntu 22.04 with kernel 5.15 also works. I can switch between my 2.4 GHz and 5 GHz networks multiple times. |
|
@dubhater : Can you confirm (when you say working) that there is no bit rate degradation when under network load. I use this simple continuous monitor command to watch the rx/tx bit rates: while true; do iw (Substitute I have noticed under load both receiving and transmitting the RX bit rate drops very low and the TX bit rate remains fairly stable. So only the RX bit rate drops when both receiving or transmitting. So following is an example of what occurs when I do a speed test: |
|
@WallyZambotti Yes, the RX speed is stable here with RTL8822CU. |
|
@dubhater Can you confirm I am using the correct repo : |
|
@WallyZambotti That looks correct. |
|
The latest update of the driver seems to be unstable and the network disappears with "Device not ready". It will work for a limited time after a reboot but then fails. lsusb and iw dev show the device is still there. |
|
@WallyZambotti Does an older version of the driver work better? How long does it work before it fails? Can you show the output of |
|
Not sure how long it is lasting. Seems to be dying over night. I might check the power settings to see if this system is going to sleep. If you need the journalctl output after a failure then we will have to wait until that happens again, until then here is segment of the messages being displayed : Do you want the full output, regardless? |
|
I am running a 8812bu adapter with rtw_8822bu right now: Can you give me some details on what you are doing when you see the performance issue? I'll try to duplicate. I git pulled earlier today. |
|
Ouch: |
Basically occurs with any net traffic. I usually test with a speed test site.
|
I used: Results: (download test) rtw_8822bu - 40.5 Mbps Geez... I see what you mean. Yes, the mt7921u is a WiFi 6 class driver but my internet service is limited to 500 Mbps and really, the number should not be that different. Test conducted on the same desktop system with both wifi devices on the same system running Debian 12 x86_64. |
|
rtw_8822bu - 40.5 Mbps @morrownr Are you able to test both those adapters on the same hardware using Windows to confirm they do get roughly the same performance? |
Well, I've never been a Windows user but I will uninstall rtw_8822bu and replace it with the out-of-kernel driver here in this repo to see what we get a little later. |
|
Testing site. Same as before: New results: (download test) 88x2bu - 523.7 Mbps (this is the vendor driver from this repo) The vendor driver is smoking rtw_8822bu. |
|
@morrownr : Explain how you enabled the "vendor" driver. If it is that good why isn't it the default? |
I first uninstalled the rtw88 driver that we are testing, then I installed the driver in this repo.
Good question. Realtek's usb team, in their infinite wisdom, has not moved over to fully standards compliance with their usb drivers so the driver in this repo will not be allowed into the Linux kernel. The rtw_8822bu driver can be as fast as 88x2bu. We just need to figure out what the issue is. It would be good if @dubhater had a rtl8812bu adapter so he can directly test but he knows he can ask me to test and provide results. He has some adapter that I do not and vice versa. In fact @dubhater is pretty sharp. I'll bet the numbers that I posted give him an idea of what is not correct. |
|
Maybe I'm using the wrong driver because I can't find any definitions for : Device 0xb812 Hang on I found a definition : |
The numbers from iw tell me what to investigate. The AP is transmitting at a low rate, most likely because the AP thinks RTL8812BU doesn't hear a lot of what the AP is transmitting.
Having the adapter makes it a lot easier. Debugging by proxy is not fun. |
|
My wife and I are dealing with health issues currently and it is slowing my activity here at my github site greatly. I may not be available much at all over the next week. While I have an extra adapter with a rtl8812bu chip, the shipping from my location is rather expensive so if it was a situation where I was shipping several adapters, I could probably justify the expense. I'll check in with you via email to see what we can work out. |
|
@morrownr I have compared list of devices supported by the in-kernel driver and this one and see that 2 devices are not supported by the upstream driver: $ diff -u --color <(modinfo /lib/modules/6.6.47-generic-1rosa2021.1-x86_64/kernel/net/wireless/88x2bu.ko.zst | grep ^alias | sort -u) <(modinfo /lib/modules/6.11.2-generic-1rosa2021.1-x86_64/kernel/drivers/net/wireless/realtek/rtw88/rtw88_8822bu.ko.zst | grep ^alias | sort -u)--- /dev/fd/63 2024-10-10 14:12:41.720801602 +0300
+++ /dev/fd/62 2024-10-10 14:12:41.721801620 +0300
@@ -1,5 +1,4 @@
alias: usb:v04CAp8602d*dc*dsc*dp*icFFiscFFipFFin*
-alias: usb:v056Ep4011d*dc*dsc*dp*icFFiscFFipFFin*
alias: usb:v0846p9055d*dc*dsc*dp*icFFiscFFipFFin*
alias: usb:v0B05p1841d*dc*dsc*dp*icFFiscFFipFFin*
alias: usb:v0B05p184Cd*dc*dsc*dp*icFFiscFFipFFin*
@@ -16,7 +15,6 @@
alias: usb:v2001p331Cd*dc*dsc*dp*icFFiscFFipFFin*
alias: usb:v2001p331Ed*dc*dsc*dp*icFFiscFFipFFin*
alias: usb:v2001p331Fd*dc*dsc*dp*icFFiscFFipFFin*
-alias: usb:v20F4p805Ad*dc*dsc*dp*icFFiscFFipFFin*
alias: usb:v20F4p808Ad*dc*dsc*dp*icFFiscFFipFFin*
alias: usb:v2357p0115d*dc*dsc*dp*icFFiscFFipFFin*
alias: usb:v2357p0116d*dc*dsc*dp*icFFiscFFipFFin* |
|
Hi @mikhailnov
Let me see if I am understanding correctly. You are saying that the out-of-kernel driver in this repo has two more vid-pids than does the in-kernel rtw88_8822bu ? If that is correct, I am aware of this. It is on a list of things to do that I keep. Would you be interested in helping me put together a patch to submit to linux-wireless? |
|
Yes, correct, thanks for reply! I can try to help, which help is needed? Unfortunately I do not have such hardware to test. |
|
Is just adding vid-pids into the in-kernel driver not enough? |
I can put together the patch which we will send in to linux-wireless to be merged into the kernel, however, I need help verifying that what we are doing is correct.
It is as long as things are correct. I accidently made a mistake several months ago and added a 8822cu vid-pid to the 8821cu driver as part of a large patch. I have since sent in a patch to correct the error but we need to be very careful so if you can check my work, that would be great. |
|
Of course I can :-) Feel free to write here or at [email protected] |
|
I can report after the last update from github (https:/github.com/lwfinger/rtw88) that the bit rate dropping under load issue seems to have been fixed. My RX rate is now the same or better than the TX rate and latest speed test to 2.4 GHZ router (114.5 Mbps download, 109.1 Mbps upload). Since the connection is capped at 100 Mbps that looks perfect. |
Greetings to anyone that reads this message.
This Issue is where we coordinate and take bug reports for the effort to improve the 8822bu in-kernel driver. The 8822bu in-kernel driver supports the same adapters as the 88x2bu driver in this repo so if you are here for the driver in this repo, you can help us test.
Note: I am also going to send the users of 8822cu based adapter to this message as rtw88 (link is below) supports the 8822cu as well). Therefore, we need users making reports to specify whether they are using a 8822/12bu based adapter or a 8822/12cu based adapter.
An effort is underway to improve the support for the rtl88x2bu chips in the rtw88 in-kernel driver series. The driver that we are using for testing is available 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. You do need to Blacklist the existing 8822bu driver in the kernel if you are using kernel 6.2 or later so look for how to do that in the README.
We welcome you to test and report on this rtw88 driver. Your testing will help us improve the driver in the Linux kernel. 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
What we need tested:
USB 3 support. Please test with USB 3 ports and USB 2 ports. Even USB 1.x if you have them. Check to see if the usb port is set to usb3 mode in a usb3 port and the same with USB 2 ports.
We need testing and report on AP mode, monitor mode, IBSS and PSP.
Reports go in this issue.
The text was updated successfully, but these errors were encountered: