Project: Improve rtl8821/11cu rtw88 in-kernel driver. Need help... #115
Comments
|
The repo https://github.com/lwfinger/rtw88 contains a backport of the latest wireless-next code for kernel 5.4 and newer. The driver really improved since the initial release in kernel 6.2 and works pretty well with my adapters. Except AP mode, which is still broken. |
|
Thanks for the info. I was aware of Larry's repo but did not know it was tracking wireless-next. I have been testing rtw88_8822bu and it has been making good progress in managed mode up through 6.5, which is the last version I have tested. I've had a couple of reports here about rtw_8821cu not working so I started testing my 8811cu adapter and it is not working. I've been in contact with some devs/users I know that have 8811cu adapters so as to get them to test. I'm trying to collect the info so as to try to determine what the problem is. My overall goal is to shift my priority to helping with the mac80211 drivers, whether it be Mediatek or Realtek chipsets and I hope I can eventully sunset the 8822bu and 8821cu drivers here as I need to use my time on other things. Cheers |
|
Anything I can do as an end user with 8811cu to help? The exact device that I have is MERCUSYS AC650. I've been testing every kernel release after 6.2 (and also that out-of-tree wireless-next port) to see if it's working but never really bothered to contact anyone... I'll grab some dmesgs for you soon, I remember that logs were different between iwd and wpa_supplicant. |
|
Due to some health problems, this issue has slipped lower on my priority list but I would like to see information flowing in so that maybe we can get to the point that we know where the important problems are. The rtl8812bu driver in rtw88 is in much better shape that the driver for rtl8811cu. It is not clear why which is why I posted this issue. |
|
@morrownr |
|
Hi @Salz I took a look at the files you sent. What kernel version are you using? Also, have you checked the firmware? The location of the Realtek firmware is a few lines from the top. |
Linux 6.6.1 from kernel.org. In case it matters I also attached my
Just checked them, the files in /lib/firmware/rtw88 are identical to from the kernel firmware repository. |
|
I've just tested an 8821cu adapter (0bda:c811) with Kali Linux, kernel 6.5.0-kali3-amd64. While the driver from this repository (8821cu-20210916) worked fine. |
|
Testing on an older ArchLinux with kernel 6.4.5-arch1-1, there were various errors in dmesg but the adapter was working. There was no attempt to load the rtw8821c_fw.bin firwmare. Is that firmware really needed, or not, and the attempt to load it is what's causing the issue? |
|
Sorry, my bad. |
|
I was able to do a little more testing here a couple of days ago. I was using Debian 12. Base Debian 12 comes with kernel 6.1 lts but they do release later kernels at times. I uploaded kernel 6.5. Interestingly, the firmware was in place but kernel 6.1 did not have the driver. Kernel 6.5 fixed that. What I saw with that setup is that driver loaded and an interface was formed. When trying to connect, it would fail and it looked like a problem with security. Interestingly, the in-kernel driver for the 8812bu chipset does connect and work well. I really need more time to document the details of the failure and time to start looking around in the code of rtw88. One thing I have noticed using the rtw88 driver for the 8812bu chipset is that rtw88 is not full featured yet. However, these out-of-kernel drivers are also missing features. My opinion is that the best supported chipsets overall for Linux users is the mt7610u, mt7612u and mt7921au. We should have adapters based on the new mt7925 chipset (wifi 7) soon since the driver is now in the Linux kernel. I'd say we may see them available at some point in the second half of 2024. |
|
2024? Really? Wow. |
Hello, i have the same issue on linux kernel 6.2.0 and pi 400 with linux kernel6.6.6-v8(built by myself). I don't see the log I tried two versions of rtw8821c_fw.bin, and both had the Add i tried to capture the authentication packet on the other pc(windows), but no authentication packet was captured, so I guess the kernel sent the packet to the wifi network card, but the wifi network card did not send it. The software i use to capture packets is Do you have any other updates? |
Right now I'm thinking that we will see cards (PCIe) in the first half of 2024 and usb adapters in the second half of 2024. That applies to the mt7925 chipset from Mediatek. I noticed a WiFi 7 PCIe card based on an Intel chipset for sale yesterday. The Intel driver is also already in the kernel. I forget which kernel it was first included in. I am still not seeing any information regarding Realtek and WiFi 7 for usb. The only thing for sure is that Realtek can't continue with out-of-kernel drivers, such as this one, as they will no longer work starting with WiFi 7. |
|
Thanks for the additional information.
This is consistent with what I am seeing. My latest test is with kernel 6.5. The driver loads, an interface is created but I cannot get a connection. The lack of an authentication packet would cause this. I also have an adapter based on the rtl8812bu chipset, which is also supported in rtw88. It works as expected. Maybe we can compare code and find the difference? Larry, I am adding you to this message in the hopes that maybe you have an idea how we need to proceed. I started this issue in my rtl8821cu repo with the goal of finding out why the rtw88 support for the rtl8821cu chipset is broken. What we have discovered so far: With kernel 6.2 and later, rtw88_8821cu is loading and an interface is being formed. When a connection is attempted, it fails. It appears that no authentication packet is being sent. Any help appreciated. |
|
Since you have packet capture, could you please attach it to this issue. |
|
The above message from lwfinger is requesting a packet capture file. Could you be so kind as to attach a packet capture file in a reply? I added lwfinger to this issue as he maintains a downstream repo for rtw88 and might be able to provide some guidance based on what we are seeing. Thanks. |
|
Hi, I'm chiming in and add my observations. I have two 88x1cu cards. Both tested on Arch Linux with kernel 6.6.7. One is 8821cu (0bda:c820), the one with bluetooth support. It works very well with the rtw88 driver. Bluetooth works okay as well (with the in-kernel btusb driver) and BT can work simultaneously with Wi-Fi. Almost felt too good to be true... The other is 8811cu (0bda:c811 after modeswitch), and it does not work with rtw88. Haven't tested 8821cu from this repository, but it works okay on Windows. With rtw88, the symptom is the same--sending auth to AP for 3 times before authentication timed out. I have not done any packet capture myself, but I believe it should be the same issue as @wandou2018. I think what he meant was that while his monitor setup is okay, there was not a single packet sent by the 8811cu in the capture. In other words, 8811cu was not sending any packets, or the power was way too low to be captured, maybe? Either way, RX seems okay, but TX is not working at all. |
BT and WiFi can work simultaneously in the same adapter but the WiFi has to be limited to USB2 or there will be interference with BT. Since your card is USB2, it works. Where the problem comes in is if an adapter has a AC1200 or later chipset and is capable of USB3 WiFi. If makers turn on BT support, they have to limit WiFi to USB2 which is a serious limitation on AC1200 or later chipsets.
I have two adapters that are 8811cu chips and vid/pid 0bda:c811 and they are single-state so no need for usb_modeswitch. Neither work with rtw88... from Mainline. I tested kernel 6.7 rc6 this morning. The situation is as many 8811cu users have reported: A wifi interface is created. An attempt to connect is made and the connection fails. I've tested with numerous distros and kernels. This has been reported by numerous users. It is interesting that your multi-function 8821cu based adapter does work. Maybe that is another hint as to what the problem is. |
|
Been tracking this... unfortunately I don't have any additional variants of ICs, so have not commented as yet. But am tracking, in case I can help in any way, just let me know.... Oh, and happy holidays! |
Sorry, it means that I can't capture any packets sent from the rtl8811cu, but I can capture packets from other intel wireless cards . so I can't provide the packets. |
Yes, my rtl8811cu works fine on Windows. And on linux, RX works because it has wifi list information. So I think this should be a firmware issue with |
I am not sure if it's a firmware issue, as I made several more tests with my
My |
|
It is clearly not a firmware issue. The standard firmware extracted from your listed header file is identical with the one currently in rtw88. I do not have a copy of 8821cu-20210916. Could you please post your tarball? Thanks. |
https://github.com/morrownr/8821cu-20210916 This thread is in Issues in the above repo. Background: I started this issue a few months ago after seeing a fairly constant flow of users having problems with rtw88. Why would users of the 8821cu/8811cu chipset be reporting problems with rtw88 in a repo that is the out-of-kernel driver? Because I actively encourage the users of this repo to try rtw88. This flow of problem reports caused me to take the time to test rtw88 and I found it not to be working. For me, a wifi interface is created. When I try to connect, the connection fails. This seems to be common. It was a surprise to me when the above user said his 8821cu (multi-function chipset) was working with rtw88. I agree that this does not seem to be a firmware issue. Many Linux users are not familiar with in-kernel (AKA in-tree) drivers and how they different from what they have experienced with installing drivers for Windows or installing the out-of-kernel Linux drivers so here is a short blurb for those that are following along: Linux in-kernel wifi drivers consist of one or more driver files and one or more firmware files. The driver, actually called module if we are to be correct with the terminology, is never only one file. What we normally call the driver files are in the kernel. The firmware files are in the distro. When a new kernel kernel flows into your system during a update/upgrade, the driver is automatically updated because the driver is part of the kernel. A new kernel does not update/upgrade the firmware files. The firmware can be updated by the maintainers of your distro and it will flow in just like new kernels do but will have a name similar to Firmware for bla bla. Users can also upgrade the firmware files on their own. Larry, I have an extra 8811cu based adapter if you are interested. I can mail it to you if you want. I really would like to see this fixed and I am not yet familiar enough with in-kernel programming to be much help but it is on my to-do list to work on. Regards, |
|
Do a 'git pull' and 'sudo cp rtw_8821c_fw.bin /lib/firmware/rtw88/.'. Does that change the actions of the 8811 modules? |
|
The chip 8821ce is not a very good one. I even had to domate an RTL8192CU dongle to my neighbor whose 8821ce would not work even in Windows. |
|
Thanks to your contribution my Comfast usb wifi adapter (rtl8821cu) came back to life in Linux Mint. Greetings!. |
|
Kernel 6.8-rc3 + Mercusys MU6H (RTL8811CU): no TX. |
|
@5kft I don't think that will fly. Anyway, the hardware-controlled blinking I implemented for 8821au is temporary. It tells me if the chip thinks it's transmitting something, which has been useful a few times. But there is a downside: the LED blinks all the time in AP mode because it's transmitting beacons all the time. (By the way, that old problem is fixed now. It is transmitting beacons. AP mode should work better now.) The other problem is there is no way to turn off the LED. The proper solution is to register the LED with the kernel's LED subsystem, which will allow the user to turn it off, and to tell mac80211 to make the LED blink. @gtisan I guess the connection is not as stable as it appears. Try the latest commit. |
|
@dubhater Makes sense - thanks 👍 |
|
The latest commit lwfinger/rtw88@4a1ee64 fixes AP mode. The connection looks stable now. Thanks all for the hard work. |
|
I can confirm that AP is working fine now also for 8822cu. Thanks a lot ! |
|
@5kft Remind me again what kind of board you were testing here? #115 (comment) I want to mention it and the before/after numbers in the RX aggregation commit message. |
|
@5kft Also, can you test the speed again with RX aggregation disabled? diff --git a/drivers/net/wireless/realtek/rtw88/rtw8821c.c b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
index 3e30e6169729..e7473dff9c14 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8821c.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
@@ -1281,6 +1281,7 @@ static void rtw8821c_rx_aggregation(struct rtw_dev *rtwdev, bool enable)
u8 size, timeout;
u16 val16;
+ return;
rtw_write32_set(rtwdev, REG_RXDMA_AGG_PG_TH, BIT_EN_PRE_CALC);
rtw_write8_set(rtwdev, REG_TXDMA_PQ_MAP, BIT_RXDMA_AGG_EN);
rtw_write8_clr(rtwdev, REG_RXDMA_AGG_PG_TH + 3, BIT(7));I want to see if this commit by itself has an effect on the speed: lwfinger/rtw88@98de16f |
@dubhater Sure, this is an ARM Cortex-A53-based board (based on the NanoPi NEO Core2), running arm64 Debian and stable Linux kernel 6.10.x. |
@dubhater Here you go ( Test with RX aggregation disabled (i.e., addition of the "return" statement as requested above, results are consistent over several runs): Downloads are capped at ~3MB/s as well: Same test run with RX aggregation enabled (added "return" statement removed): Downloads reach ~30MB/s+ (an order of magnitude faster than with RX aggregation disabled): Thanks again for these changes! |
|
@5kft Thanks for testing again. By the way, does your adapter have bluetooth? |
Alas, it does not have BT - it's Wi-Fi only (EDUP AC600M) |
|
I have one usb wifi adapter that has bluetooth capability and it is powered by a rtw_8822cu chip. What can I test for you? FYI: Sorry about the delay in testing AP mode for rtw_8812au. I seem to have had a hardware failure in my AP mode test system and am having to sort that out. Not sure when I will be back in business for that but I can handle other things like managed, monitor and P2P mode testing. |
|
@morrownr It's okay, I only needed to know what to write in the commit message, RTL8821CU or RTL8811CU. |
|
Sorry for seeing this late, been travelling.. @dubhater great work with the rx aggregation. I will give it a spin using my lm842 (8822CU) adapter on my slow i.MX6SX board that I have reported issue on before that seems to have been related to lack of tx/rx aggregation (8821AU started to work fine after aggregation was added). Will keep you posted. I will try it on my mainline kernel, is it enough to cherry-pick the 4 patches about this from wirelss-next (https://lore.kernel.org/linux-wireless/[email protected]/T/#t)? BTW @dubhater I can donate a 8822CU adapter (LM842) if you are lacking such a device, good to be able to test bluetooth also.. |
An alternative to cherry-picking patches is to use our dev repo where the patches are in place before they go upstream: https://github.com/lwfinger/rtw88 If you aren't familiar with the dev repo, just blacklist existing in-kernel drivers such as rtw88_8821cu and install the dev repo. It uses different driver names so as not to conflict... rtw_8821cu. That would make it as easy as a git pull to keep up while testing. |
Sure, I can try it on the dev repo also. I have used that repo for troubleshooting issues seen in the mainline kernel from time-to-time and to do benchmarks, so I'm quite familiar with it. |
|
@belzerus Thank you for your offer. I believe one of those LM842 is on its way to me right now. |
|
Just a short update regarding 8822cu (lm842). I reverted the commit "wifi: rtw88: Avoid using macid 0 in AP mode" and add the patch "wifi: rtw88: assign mac_id for vif/sta and update to TX desc" from mailing list. How is going with this repo, will be updated in future ? |
|
I can confirm that replacing "wifi: rtw88: Avoid using macid 0 in AP mode" with "wifi: rtw88: assign mac_id for vif/sta and update to TX desc" solves the connection speed issue. |
That is unknown. Before Larry passed away, he gave dubhater and I admin rights so as to finish the project we were working on which included getting some drivers up to speed and adding drivers for rtl8821au, rtl8812au and rtl8814au. The work on the first 2 is under review by the Realtek Linux wifi gatekeeper. He had requested a lot of cleanup so dubhater has been busy with that. What was unknown when this project started was just how many problems there were in rtw88. We have seen a steady flow of small patches to fix little things this entire year and they are still going in. Is rtw88 (in kernel) much better now than it was? Oh, yes. To address the issue of 2 patches both of you speak of, I have lost track of where we are. What you might do is check wireless-next to see what the resolution was on those two patches as I am pretty sure this was resolved the result was applied. Back to the question about the future of the rtw88 repo; I do not have time to maintain this repo going forward. What I might be willing to do if it appears there is a need for it is fork it to this github site and set up admin right for the fork for 1, 2 or 3 folks that have the skills and desire to maintain it. I could help some. |
|
These 2 patches fixes AP mode and are in linux-next-20240911
1 is already in our repo and 2 is a replacement for the commit "wifi: rtw88: Avoid using macid 0 in AP mode" from our repo. Does anybody ran AP mode in 5 Ghz ? Station mode for 5 Ghz works well. I use hostapd 2.11 with this settings: The log from starting hostapd : "iw phy0 info" give me these freq in band2: |
|
@gtisan, 5GHz works fine here. It looks like your wireless regulatory database is not working properly. Do you have a signed wireless-regdb installed? |
|
I think yes, but looking at the kernel boot log it seems that is not working : 1399576044.382267 INFO 0 0 [kernel]: cfg80211: Loading compiled-in X.509 certificates for regulatory database |
|
-2 means „file not found”. |
|
I put regulatory.db in /lib/firmware, is it wrong ? |
|
I think the files go in: /usr/lib/firmware They are users space files for a reason. |
|
According to the Makefile from here https://git.kernel.org/pub/scm/linux/kernel/git/wens/wireless-regdb.git/tree/Makefile, I put the files in these locations, but I still have the same errors. Does anybody has a hint ? ls /usr/lib/crda/ -R/usr/lib/crda/: /usr/lib/crda/pubkeys: ls /lib/firmware/regulatory*/lib/firmware/regulatory.db /lib/firmware/regulatory.db.p7s |
|
Did you reboot after you added the files? If that didn't help, try putting them in /usr/lib/firmware. :) And you also need to set the country code with Your distro doesn't provide these files in a package? |
|
Here is where the files are in the system I am working at currently: (Debian 12) |
Greetings to anyone that reads this message.
It was reported that the rtw88 in-kernel driver for the rtl8821cu/rtl8811cu chipsets was broken. So... we decided to make it better. Five patches have now gone into the Linux kernel (6.9) so things are better. While things are better, it is good to continue testing and make things very good.
If you are willing to help, here is a basic plan:
sudo sh remove-driver.sh.The rtw88 repo shown above is a downstream repo from the Linux kernel. It focuses on the rtw88 driver series. If you have test results or questions, post in this issue.
Regards,
@morrownr
The text was updated successfully, but these errors were encountered: