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: |
|
To: @kimocoder and others
Let me add something to @dubhater 's request: He can also make good use of adapters with mt7921au, mt7612u, mt7610u and mt7601u chips. Alfa makes the AXM, ACM and ACHM which would cover the mt7921au, mt7612u and mt7610u respectively. Certainly any donated adapters do not have to be Alfa but Alfa does make good adapters. I was planning to donate funds or adapters with the listed chips to @dubhater once some of the current work has gone upstream and things have settled down. If I ship, it is a long way from my place to @dubhater 's place we live a half a world apart so if anyone in Europe has adapters with the 6 listed chips and you are willing to donate them to @dubhater , it would be a very good thing. I've had a 88x2bu repo up for several years. Almost all product that has shipped with those chips has been the rtl8812bu chip. The adapters with the 8822bu are limited to USB2 as noted on Realtek's website. I'm sure it has to do with the bluetooth/USB3 interference issue as noted by an Intel White Paper from about 12 years ago. Who would want a 8822bu when the 8812bu is a LOT faster? |
|
@5kft It's possible I copied the wrong thing from the official driver. Does it look more normal with this? diff --git a/drivers/net/wireless/realtek/rtw88/rtw8821a.c b/drivers/net/wireless/realtek/rtw88/rtw8821a.c
index e2cb323f4fd2..2d738c3f8c75 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8821a.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8821a.c
@@ -1683,7 +1683,7 @@ static void rtw8821a_query_phy_status(struct rtw_dev *rtwdev, u8 *phy_status,
}
} else { /* OFDM rate */
for (i = RF_PATH_A; i < rtwdev->hal.rf_path_num; i++) {
- val = phy_sts->gain_trsw[i];
+ val = phy_sts->pwdb_all >> 1;
pkt_stat->rx_power[i] = (val & 0x7F) - 110;
rssi = rtw_phy_rf_power_2_rssi(&pkt_stat->rx_power[i], 1);
dm_info->rssi[i] = rssi; |
|
Thanks @dubhater, unfortunately however, that change has no impact, it still reports I just rebuilt and re-tested using @morrownr's 8821au driver, and it consistently shows
(FWIW, I don't recall ever seeing |
|
In that case, the hardware really is seeing 0 dbm. Both drivers adjust the RX gain every two seconds in order to minimise RX errors, but they don't calculate it exactly the same way, so they end up with slightly different values. I guess that's why the signal strength is different. |
|
@5kft Can you retest the speed with and without aggregation, please? Like you did with the RTL8811CU. |
Hi @dubhater , absolutely - here you go: Both tests run via Test with RX aggregation disabled (i.e., addition of the "return" statement at the beginning of Default current top-of-tree code with RX aggregation enabled: |
|
@dubhater Just a side note, with this adapter the reported signal strength is still behaving oddly for this driver. In running the requested tests above, I ran a few Except for this interesting -54 dBm case, it almost always reports 0 dBm, however. For these tests, the AP is actually in another room, through two walls. |
|
Thank you for testing again. That signal strength is weird. If you want, you can check what the hardware is reporting: diff --git a/drivers/net/wireless/realtek/rtw88/rtw8821a.c b/drivers/net/wireless/realtek/rtw88/rtw8821a.c
index d1bb3c03c473..18fa7939372e 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8821a.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8821a.c
@@ -1629,6 +1629,7 @@ static void rtw8821a_query_phy_status(struct rtw_dev *rtwdev, u8 *phy_status,
} else { /* OFDM rate */
for (i = RF_PATH_A; i < rtwdev->hal.rf_path_num; i++) {
val = phy_sts->gain_trsw[i];
+ pr_err("gain_trsw[%d] = 0x%02x pwdb_all = 0x%02x\n", i, phy_sts->gain_trsw[i], phy_sts->pwdb_all);
pkt_stat->rx_power[i] = (val & 0x7F) - 110;
rssi = rtw_phy_rf_power_2_rssi(&pkt_stat->rx_power[i], 1);
dm_info->rssi[i] = rssi;It will print one line for each received packet (two if you use RTL8812AU). |
Hi @dubhater, I captured a few seconds of reporting and hid it within a dropdown so as to not spam this issues thread: Expand this to see a capture of what the hardware is reporting for the signal strength
|
|
That looks normal. 0x38 should result in -54, and 0x40 in -46. Can you follow the code and find out where it goes wrong? The "destination" is rx_status->signal (maybe also rx_status->chain_signal) in rtw_rx_fill_rx_status() in rx.c. |
|
I took a quick look and |
|
That explains it. Now to find out why some frames don't have the PHY status. This is controlled by BIT_APP_PHYSTS in REG_RCR. As far as I can tell it's never cleared. Is it the same with rtw8811a_fw.bin? diff --git a/drivers/net/wireless/realtek/rtw88/rtw8821a.c b/drivers/net/wireless/realtek/rtw88/rtw8821a.c
index f69e60a06719..41fd7d82cb67 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8821a.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8821a.c
@@ -3974,7 +3974,7 @@ static const struct rtw_reg_domain coex_info_hw_regs_8821a[] = {
const struct rtw_chip_info rtw8821a_hw_spec = {
.ops = &rtw8821a_ops,
.id = RTW_CHIP_TYPE_8821A,
- .fw_name = "rtw88/rtw8821a_fw.bin",
+ .fw_name = "rtw88/rtw8811a_fw.bin",
.wlan_cpu = RTW_WCPU_11N,
.tx_pkt_desc_sz = 40,
.tx_buf_desc_sz = 16, |
I'd be happy to try this, but I can't find rtw8811a_fw.bin anywhere. It's not in lwfinger/rtw88/firmware/, nor in the latest Debian firmware-realtek_20240709-1_all.deb package, and Google returns zero results when searching for this file... (I'm running Debian Bookworm...) Hope I'm not missing something obvious here... |
|
I'm not sure what happened to it. You can still find it here: https://github.com/lwfinger/rtw88/blob/8821au_8812au/rtw8811a_fw.bin |
|
I checked commit history in one year, it looks like rtw8811a_fw.bin is never in the master branch. |
I think we should inform the author of hwdata to correct it, your adapter has a RTL8811AU chip actually. |
|
@dubhater The "zero signal strength" problem actually occurs when signal strength is queried while wireless traffic is taking place. The same problem happens with the rtw8811a_fw.bin firmware as well - there is no change in behavior between the two firmwares. I found that if I connect to the board via serial console (i.e., not via ssh over Wi-Fi), and then run If I ssh into the board via Wi-Fi and do the query, it is almost always reported as zero because Wi-Fi traffic is being transferred for the ssh session. |
That is a good idea but there are likely several ID descriptions that need correcting. I authored the vid/pid files for the rtw_8812au and rtw8821/11au in Larry's rtw88 so I know they are accurate. Are you volunteering to handle this? Here is the history in case you haven't been watching this for the last 10+ years: Realtek's original, and for a few versions, vendor driver was a combined driver for the rtl8812au, rtl8821au and rtl8811au chips. Then about 5 or so years ago, they released separate drivers which has led to a lot of confusion in the years since. The bug reports that I get these days are mostly ones when I have to send users to the other driver. This is confusion that needs to go away. Getting the drivers in mainline will help we still need the ID wordage to be accurate. |
|
@a5a5aa555oo rtw8821a_fw.bin has worked fine so far, so we don't need rtw8811a_fw.bin. I opened a pull request to correct the description of 0bda:1a2b. It was rejected because that repository is not the right place for it. They directed me to http://www.linux-usb.org/usb-ids.html. I'm still waiting to hear back. The current list of IDs is from July, so there is hope. |
|
I read the guideline and found it hard to correct them but im trying it with 0bda:1a2b and 0bda:2005~ |
|
I submitted some change requests to that site, but I don't know if they will accept them. :( https://usb-ids.gowdy.us/read/UD/0bda/2005
@morrownr |
|
@dubhater Regarding the signal strength issue, what do you think about the following fix for the 8821a (see diff below)? My thinking is this: For the 8821a, most packets aren't reporting a PHY status even though BIT_APP_PHYSTS is set in REG_RCR. (E.g., I don't see this signal strength issue with my 8821cu adapter, so it appears PHY status reporting is working for that adapter.)
The fact that the signal value is always copied in rx.c regardless makes this logic actually pretty reasonable. Thoughts? index 7031ca176..5e3b62ac4 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8821a.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8821a.c
@@ -1708,6 +1708,7 @@ static void rtw8821a_query_rx_desc(struct rtw_dev *rtwdev, u8 *rx_desc,
u32 desc_sz = rtwdev->chip->rx_pkt_desc_sz;
struct ieee80211_hdr *hdr;
u8 *phy_status = NULL;
+ static s32 prev_signal_power = 0;
memset(pkt_stat, 0, sizeof(*pkt_stat));
@@ -1738,6 +1739,9 @@ static void rtw8821a_query_rx_desc(struct rtw_dev *rtwdev, u8 *rx_desc,
if (pkt_stat->phy_status) {
phy_status = rx_desc + desc_sz + pkt_stat->shift;
rtw8821a_query_phy_status(rtwdev, phy_status, pkt_stat);
+ prev_signal_power = pkt_stat->signal_power;
+ } else {
+ pkt_stat->signal_power = prev_signal_power;
}
rtw_rx_fill_rx_status(rtwdev, pkt_stat, hdr, rx_status, phy_status); |
|
@5kft That's what I was thinking too, but only if the missing PHY status is normal, if it's like that with the official driver too. I haven't checked yet. (Also prev_signal_power has to go in a struct, rtw_dev, rtw_phy, something like that. Otherwise if you have two devices using this driver at the same time the signal strength will be incorrect.) |
|
@dubhater Totally makes sense. |
|
@5kft It's the same with the official driver. Fortunately, not knowing the signal strength for some frames is very normal, not just for Realtek chips. mac80211 already supports this: diff --git a/drivers/net/wireless/realtek/rtw88/rx.c b/drivers/net/wireless/realtek/rtw88/rx.c
index 66f9419588cf..4f9fce3f79b1 100644
--- a/drivers/net/wireless/realtek/rtw88/rx.c
+++ b/drivers/net/wireless/realtek/rtw88/rx.c
@@ -235,10 +235,14 @@ void rtw_rx_fill_rx_status(struct rtw_dev *rtwdev,
else
rx_status->bw = RATE_INFO_BW_20;
- rx_status->signal = pkt_stat->signal_power;
- for (path = 0; path < rtwdev->hal.rf_path_num; path++) {
- rx_status->chains |= BIT(path);
- rx_status->chain_signal[path] = pkt_stat->rx_power[path];
+ if (pkt_stat->phy_status) {
+ rx_status->signal = pkt_stat->signal_power;
+ for (path = 0; path < rtwdev->hal.rf_path_num; path++) {
+ rx_status->chains |= BIT(path);
+ rx_status->chain_signal[path] = pkt_stat->rx_power[path];
+ }
+ } else {
+ rx_status->flag |= RX_FLAG_NO_SIGNAL_VAL;
}
rtw_rx_addr_match(rtwdev, pkt_stat, hdr); |
@dubhater This is perfect - very nice! I can confirm that this change works like a charm. Thank you! |
|
Hi fellas, I wrote my experiences with the I wasn't sure what would be helpful or not so I pretty much just put everything I could think of there. I won't subscribe to this issue here since it's pretty active (and I doubt I'd be of any help either) but I'll try to keep an eye for replies on the linked issue. Cheers! |
|
Hello, I have tried using https://github.com/morrownr/8821au-20210708 , I have found this in https://forums.linuxmint.com/viewtopic.php?t=376909 It works great, but i'm not sure about how good it works and my wifi speed is not great, so can't really do a wifi test speed with over 50 mbps. neofetch lsusb I have read tukkek post, it seems kinda lacking on os and other information, so I did not get any usefull information, also read several other ubuntu forums and linux forums, this was the most legit looking driver, althought it has some recent updates a less than year ago, I'm concerned a bit. If you have any more questions, I will answer them. EDIT: I did basic wifi speed test, I'm not that experienced to do other tests like mode switch or etc |
|
New update on my driver issues, I randomly got a warning report that told me that there was a driver for my NetGear usb wifi adapter, so i'm switching to that. I swear that driver appeared randomly.
|
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:
Managed mode (client) appears to be in really good shape. No outstanding issues.
Monitor mode appears to be in good shape but Active Monitor mode is not supported yet.
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. Please test and report your results.
The text was updated successfully, but these errors were encountered: