Created attachment 216735 [details] hardware details for Xiaomi Redmibook 14 II hi guys, I wonder if there is some plan to add the drivers for this wifi card, or if I can help somehow I may need directions. I attached the hardware information using pciconf -lv. Thank you.
Hi, I have a part-done driver based on the Intel wireless work I am doing using the linuxkpi framework. I would hope that once the Intel work is done most infrastructure is implemented and it'll be at most a few days to have rtw88 work well as well. Currently PCI attach and firmware loading works and then it panics due to some unimplemented memory bit. I only spent less than a day on it so far to get to this. So yes, there is a plan. It'll be a while however before anything real materialises.
@Bjoern Possible to get the WIP code up in a public place somewhere? Might encourage potential contributors to play with it and get involved. Also, will/does/might your WIP work cover RTL8821CE (bug 247495) ?
(In reply to Kubilay Kocak from comment #2) I'll share code as soon as it makes sense for people to test something. As I stated it does depend on other work being done/finished first.
Hi. Is there any progress on the driver?
Hello, I am also looking forward to progress on this driver.
Please keep an eye on freebsd-wireless in the next week or so.
*** Bug 247495 has been marked as a duplicate of this bug. ***
My computer also uses this card, hope it'll work soon :D
Hello everyone, if you feel like giving things an early try this includes the first snapshot of the driver: https://lists.freebsd.org/archives/freebsd-wireless/2021-September/000068.html I am currently mostly AFK for the next 10 days to 2 weeks but will welcome feedback anyway and it'll help to focus once I am back.
Hi there, any news? I have a RTL8821CE WiFi/BT chipset and still waiting for some love on it
(In reply to Bjoern A. Zeeb from comment #9) Hello, I've read through the Wiki, but I don't find how should I test this, do you mind providing some instructions? (I'm new to BSDs) Thanks a lot!
Is there an ISO or something? If not how can I compile the entire OS or patching or whatever to test this?
There is an update on the freebsd-wireless mailing list: https://lists.freebsd.org/archives/freebsd-wireless/2022-April/000365.html
Lenovo IdeaPad 3. Works fine under Linux which runs the browser I'm using to write this. $ lspci 0000:01:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8822CE 802.11ac PCIe Wireless Network Adapter [10ec:c822] Subsystem: Lenovo RTL8822CE 802.11ac PCIe Wireless Network Adapter [17aa:c123] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 149 IOMMU group: 13 Region 0: I/O ports at 3000 [size=256] Region 2: Memory at 52000000 (64-bit, non-prefetchable) [size=64K] Capabilities: <access denied> Kernel driver in use: rtw_8822ce Kernel modules: rtw88_8822ce FreeBSD (current, build Apr 7 2022) crashes during netif start. # loader.conf hw.physmem="4G" # rc.conf ifconfig_wlan0="WPA DHCP" Steps to reproduce: - boot into single mode - kldload if_rtw88 # the card was detected properly, pciconf -l shows it - /etc/rc.d/netif start wlan0 # right after wpa_supplicant starts FreeBSD croaks, please see the screenshot attached
Created attachment 233036 [details] wpa_supplicant kernel panic
(In reply to szubersk from comment #15) Which firmware version are you having under Linux? Seems the latest 8822CE does now finally support hw_scan; so could be a problem with that. If I told you how to downgrade the FW in FreeBSD would you give it another try?
(In reply to Bjoern A. Zeeb from comment #17) Yes, I'm happy to experiment! I use shared OpenZFS zpool for my Linux (primary OS) and FreeBSD (experimenting), I can change files all I want. My Linux config. szubersk laptop:~ [22670]% doas dmesg | grep rtw [ 0.713325] rtw_8822ce 0000:01:00.0: firmware: direct-loading firmware rtw88/rtw8822c_fw.bin [ 0.713328] rtw_8822ce 0000:01:00.0: Firmware version 9.9.10, H2C version 15 [ 0.713620] rtw_8822ce 0000:01:00.0: enabling device (0000 -> 0003) [ 0.713653] rtw_8822ce 0000:01:00.0: firmware: direct-loading firmware rtw88/rtw8822c_wow_fw.bin [ 0.713654] rtw_8822ce 0000:01:00.0: Firmware version 9.9.4, H2C version 15 [ 4.545053] rtw_8822ce 0000:01:00.0: start vif 00:45:e2:a5:15:1b on port 0 [ 7.513717] rtw_8822ce 0000:01:00.0: sta 34:2c:c4:72:40:40 joined with macid 0 szubersk laptop:~ [22671]% doas dpkg -S rtw8822c_wow_fw.bin firmware-realtek: /lib/firmware/rtw88/rtw8822c_wow_fw.bin szubersk laptop:~ [22672]% dpkg -l firmware-realtek Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-================-============-============-================================================== ii firmware-realtek 20210818-1 all Binary firmware for Realtek wired/wifi/BT adapters
(In reply to szubersk from comment #18) If you can copy from your Linux /lib/firmware/rtw88/rtw8822c_fw.bin to FreeBSD src/sys/contrib/dev/rtw88fw/rtw8822c_fw.bin You'll then have to rebuild modules on FreeBSD doing at least: cd src/sys/modules/rtw88fw && make obj depend all install or more easily do a kernel build and install. Let me know how that goes.
(In reply to Bjoern A. Zeeb from comment #19) I aligned the firmware to the Linux version and the result is exactly the same - kernel panic. I'll take the tip of `main` + updated firmware and rebuild whole kernel. Let's see how it goes. One thing I can confirm that without hw.physmem="4G" the module cannot be loaded.
(In reply to Bjoern A. Zeeb from comment #19) I just used `make buildkernel` + firmware from Linux to make sure everything is as it should be. Interestingly, it worked out for a while. I managed to download git and vim via pkg. Right after that the connection snapped and I lost the device. Attempts to revive it via `netif` failed. I tried unloading/loading the kernel module but it did not help. The device couldn't be detected again (not covered in the logs below) laptop# grep -E '(rtw|wlan|wpa_|dhclie)' messages | head -n80 Apr 8 09:45:57 laptop kernel: rtw880: <rtw_8822ce> port 0x3000-0x30ff mem 0x52000000-0x5200ffff at device 0.0 on pci3 Apr 8 09:45:57 laptop kernel: rtw880: successfully loaded firmware image 'rtw88/rtw8822c_fw.bin' Apr 8 09:45:57 laptop kernel: rtw880: Firmware version 9.9.10, H2C version 15 Apr 8 09:45:57 laptop kernel: rtw880: start vif 00:45:e2:a5:15:1b on port 0 Apr 8 09:45:57 laptop kernel: wlan0: Ethernet address: 00:45:e2:a5:15:1b Apr 8 09:45:58 laptop wpa_supplicant[254]: wlan0: Associated with 34:2c:c4:72:40:40 Apr 8 09:45:58 laptop kernel: rtw880: sta 00:45:e2:a5:15:1b joined with macid 0 Apr 8 09:45:58 laptop kernel: wlan0: link state changed to UP Apr 8 09:45:58 laptop wpa_supplicant[254]: wlan0: WPA: Key negotiation completed with 34:2c:c4:72:40:40 [PTK=CCMP GTK=CCMP] Apr 8 09:45:58 laptop wpa_supplicant[254]: wlan0: CTRL-EVENT-CONNECTED - Connection to 34:2c:c4:72:40:40 completed [id=0 id_str=] Apr 8 09:46:06 laptop dhclient[1859]: New IP Address (wlan0): 192.168.0.54 Apr 8 09:46:06 laptop dhclient[1863]: New Subnet Mask (wlan0): 255.255.255.0 Apr 8 09:46:06 laptop dhclient[1867]: New Broadcast Address (wlan0): 192.168.0.255 Apr 8 09:46:06 laptop dhclient[1871]: New Routers (wlan0): 192.168.0.1 Apr 8 09:49:38 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 09:52:03 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 09:52:27 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 09:52:51 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 09:57:47 laptop kernel: wlan0: link state changed to DOWN Apr 8 09:57:47 laptop kernel: rtw880: sta 00:45:e2:a5:15:1b with macid 0 left Apr 8 09:57:47 laptop wpa_supplicant[254]: wlan0: CTRL-EVENT-DISCONNECTED bssid=34:2c:c4:72:40:40 reason=0 Apr 8 09:57:53 laptop wpa_supplicant[254]: wlan0: Trying to associate with 34:2c:c4:72:40:47 (SSID='Lenhossek_3A_12' freq=2437 MHz) Apr 8 09:58:03 laptop wpa_supplicant[254]: wlan0: Authentication with 34:2c:c4:72:40:47 timed out. Apr 8 09:58:03 laptop wpa_supplicant[254]: wlan0: CTRL-EVENT-DISCONNECTED bssid=34:2c:c4:72:40:47 reason=3 locally_generated=1 Apr 8 09:58:03 laptop wpa_supplicant[254]: BSSID 34:2c:c4:72:40:47 ignore list count incremented to 2, ignoring for 10 seconds Apr 8 09:58:03 laptop wpa_supplicant[254]: wlan0: CTRL-EVENT-DSCP-POLICY clear_all Apr 8 09:58:03 laptop kernel: rtw880: invalid fw checksum Apr 8 09:58:03 laptop kernel: rtw880: failed to download firmware Apr 8 09:58:03 laptop kernel: rtw880: leave idle state failed Apr 8 09:58:03 laptop kernel: rtw880: failed to leave ips state Apr 8 09:58:03 laptop kernel: rtw880: failed to leave idle state Apr 8 09:58:03 laptop kernel: rtw880: ERROR: lkpi_hw_conf_idle: config 0x2 returned -22 Apr 8 09:58:25 laptop kernel: rtw880: failed to send h2c command Apr 8 09:58:31 laptop dhclient[1847]: My address (192.168.0.54) was deleted, dhclient exiting Apr 8 09:58:31 laptop wpa_supplicant[254]: wlan0: CTRL-EVENT-DSCP-POLICY clear_all Apr 8 09:58:31 laptop wpa_supplicant[254]: wlan0: CTRL-EVENT-TERMINATING Apr 8 09:58:31 laptop dhclient[1847]: connection closed Apr 8 09:58:31 laptop dhclient[1847]: exiting. Apr 8 09:58:31 laptop kernel: rtw880: stop vif 00:45:e2:a5:15:1b on port 0 Apr 8 09:58:31 laptop wpa_supplicant[2639]: Successfully initialized wpa_supplicant Apr 8 09:58:31 laptop kernel: rtw880: invalid fw checksum Apr 8 09:58:31 laptop kernel: rtw880: failed to download firmware Apr 8 09:58:31 laptop wpa_supplicant[2639]: wlan0: Failed to initialize driver interface Apr 8 09:58:31 laptop wpa_supplicant[2639]: wlan0: CTRL-EVENT-DSCP-POLICY clear_all Apr 8 09:58:31 laptop root[2643]: /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant Apr 8 09:58:41 laptop root[2691]: /etc/rc.d/netif: WARNING: wlan0 does not exist. Skipped.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3443476ca9e751cebbb1c467091551bf3d518814 commit 3443476ca9e751cebbb1c467091551bf3d518814 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2022-04-08 11:11:14 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2022-04-08 11:14:54 +0000 rtw88: downgrade rtw8822c firmware to 9.9.10 Firmware version 9.9.11 added support for hw_scan and is reportedly causing more problems than 9.9.10 does. Until we get a chance to test this out downgrade the firmware in order to help people testing more. Sponsored by: The FreeBSD Foundation PR: 248235 MFC after: 2 days X-MFC: just to get the reminder with the original commit X-MFC with: 73d4ebea3567f18db549638c3d897b6d6758faa4 sys/contrib/dev/rtw88fw/rtw8822c_fw.bin | Bin 202456 -> 200312 bytes sys/modules/rtw88fw/rtw8822c/Makefile | 2 +- 2 files changed, 1 insertion(+), 1 deletion(-)
(In reply to szubersk from comment #21) That is still better news than before :) I downgraded the firmware in FreeBSD main. I also put up another patch on the Wiki which should help to no longer needing to limit memory to 4G (but is not applicable to be committed to CURRENT); see this section for the link: https://wiki.freebsd.org/WiFi/Rtw88#Currently_known_issue
Thanks Bjoern! I'll test the patch soon on FreeBSD and apply sysctls to remove annoying syslog entries. To be absolutely fair, the wifi card doesn't work perfectly on Linux either. I lose the connection once in a while, I am able to recover by `ifdown wlan0; ifup wlan0` though. Also pings are not perfect (should be <30 ms). I think we could use it as the baseline, at least for my case. szubersk laptop:~/tmp [22389]% ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=377 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=92.2 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=320 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=22.2 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=25.9 ms 64 bytes from 1.1.1.1: icmp_seq=6 ttl=58 time=80.3 ms 64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=409 ms 64 bytes from 1.1.1.1: icmp_seq=8 ttl=58 time=21.7 ms 64 bytes from 1.1.1.1: icmp_seq=9 ttl=58 time=352 ms 64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=67.7 ms 64 bytes from 1.1.1.1: icmp_seq=11 ttl=58 time=27.0 ms 64 bytes from 1.1.1.1: icmp_seq=12 ttl=58 time=420 ms 64 bytes from 1.1.1.1: icmp_seq=13 ttl=58 time=442 ms 64 bytes from 1.1.1.1: icmp_seq=14 ttl=58 time=363 ms 64 bytes from 1.1.1.1: icmp_seq=15 ttl=58 time=386 ms 64 bytes from 1.1.1.1: icmp_seq=16 ttl=58 time=102 ms 64 bytes from 1.1.1.1: icmp_seq=17 ttl=58 time=432 ms 64 bytes from 1.1.1.1: icmp_seq=18 ttl=58 time=351 ms 64 bytes from 1.1.1.1: icmp_seq=19 ttl=58 time=25.9 ms 64 bytes from 1.1.1.1: icmp_seq=20 ttl=58 time=89.5 ms
(In reply to szubersk from comment #24) If things go wrong; FreeBSD currently has all auto-recovery disabled so we find the problems rather than smear over them. I am happy you are confirming that it comes up, loads firmware, and passes at least some packets. For the little testing it has seen, I am happy, especially given you have a 8822CE and not a BE. We'll keep improving things as we go along for both iwlwifi and rtw88. I think the major problem to sort out for the Realtek drivers is the 4G limits and we need a solution we can put into the tree. I'll keep you updated on that. Thanks a lot for all the testing you are doing and all the feedback!
Looks like we reached stability compared to Linux. I just: - git-pulled the most recent `main` changes and applied the "4G hack" - add SYNCDHCP to wlan0 (setting up the initial connection takes ~10-15 seconds) to keep the boot process consistent - applied desired sysctls in `/etc/sysctl.conf` - compiled and installed kernel - reboot The system booted fine (with SYNCDHCP workaround, otherwise the connection is established ~5 seconds after the login prompt shows up), pings to 1.1.1.1 are <30 ms (better than Linux!). Since I didn't have X11 I run ``` pkg install xorg sddm lxqt ``` The transfer rate was not astonishing but nothing unusual happened. Once graphical interface was installed I left the laptop idling. Interestingly the connection was stable during downloading but snapped for the 1st time (13:25:27) when idling. Then it went into, sort of, snap->recover loop. When I started ntpd daemon the connection was in working state. Despite sysctls, the annoying spam `rtw880: failed to get tx report from firmware` is still there but that is the least of our problems now I guess :) Once I set up Xorg I'll continue working from inside the FreeBSD and monitor the connection stability. ``` Apr 8 13:02:58 laptop login[1899]: ROOT LOGIN (root) ON ttyv0 Apr 8 13:07:42 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:12:12 laptop syslogd: last message repeated 1 times Apr 8 13:12:42 laptop syslogd: last message repeated 1 times Apr 8 13:13:09 laptop pkg[2055]: gpu-firmware-kmod-g20210330 installed Apr 8 13:13:09 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:13:09 laptop syslogd: last message repeated 3 times Apr 8 13:13:09 laptop pkg[2055]: drm-current-kmod-5.4.144.g20220223 installed Apr 8 13:13:09 laptop pkg[2055]: drm-kmod-g20190710_1 installed Apr 8 13:13:09 laptop pkg[2055]: tree-2.0.1 installed Apr 8 13:13:12 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:15:00 laptop syslogd: last message repeated 1 times Apr 8 13:15:00 laptop syslogd: last message repeated 1 times Apr 8 13:18:12 laptop syslogd: last message repeated 2 times Apr 8 13:19:51 laptop pkg[2062]: xorgproto-2021.5 installed Apr 8 13:19:51 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:19:51 laptop pkg[2062]: libXdmcp-1.1.3 installed Apr 8 13:19:51 laptop pkg[2062]: libXau-1.0.9 installed ... Apr 8 13:20:29 laptop pkg[2062]: pavucontrol-qt-1.0.0 installed Apr 8 13:20:42 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:20:42 laptop syslogd: last message repeated 1 times Apr 8 13:25:27 laptop kernel: wlan0: link state changed to DOWN Apr 8 13:25:27 laptop kernel: rtw880: sta 00:45:e2:a5:15:1b with macid 0 left Apr 8 13:25:27 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED bssid=34:2c:c4:72:40:40 reason=0 Apr 8 13:25:33 laptop wpa_supplicant[257]: wlan0: Trying to associate with 34:2c:c4:72:40:47 (SSID='Lenhossek_3A_12' freq=2437 MHz) Apr 8 13:25:43 laptop wpa_supplicant[257]: wlan0: Authentication with 34:2c:c4:72:40:47 timed out. Apr 8 13:25:43 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED bssid=34:2c:c4:72:40:47 reason=3 locally_generated=1 Apr 8 13:25:43 laptop wpa_supplicant[257]: BSSID 34:2c:c4:72:40:47 ignore list count incremented to 2, ignoring for 10 seconds Apr 8 13:25:43 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-DSCP-POLICY clear_all Apr 8 13:25:47 laptop wpa_supplicant[257]: wlan0: Trying to associate with 34:2c:c4:72:40:40 (SSID='Lenhossek_3A_12' freq=5240 MHz) Apr 8 13:25:48 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:25:48 laptop kernel: rtw880: sta 00:45:e2:a5:15:1b joined with macid 0 Apr 8 13:25:48 laptop kernel: wlan0: link state changed to UP Apr 8 13:25:48 laptop wpa_supplicant[257]: wlan0: Associated with 34:2c:c4:72:40:40 Apr 8 13:25:48 laptop wpa_supplicant[257]: wlan0: WPA: Key negotiation completed with 34:2c:c4:72:40:40 [PTK=CCMP GTK=CCMP] Apr 8 13:25:48 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-CONNECTED - Connection to 34:2c:c4:72:40:40 completed [id=0 id_str=] Apr 8 13:25:56 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:25:56 laptop dhclient[4584]: New IP Address (wlan0): 192.168.0.54 Apr 8 13:25:56 laptop dhclient[4588]: New Subnet Mask (wlan0): 255.255.255.0 Apr 8 13:25:56 laptop dhclient[4592]: New Broadcast Address (wlan0): 192.168.0.255 Apr 8 13:25:56 laptop dhclient[4596]: New Routers (wlan0): 192.168.0.1 Apr 8 13:26:12 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:30:48 laptop kernel: wlan0: link state changed to DOWN Apr 8 13:30:48 laptop kernel: rtw880: sta 00:45:e2:a5:15:1b with macid 0 left Apr 8 13:30:48 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED bssid=34:2c:c4:72:40:40 reason=0 Apr 8 13:30:54 laptop wpa_supplicant[257]: wlan0: Trying to associate with 34:2c:c4:72:40:47 (SSID='Lenhossek_3A_12' freq=2437 MHz) Apr 8 13:31:04 laptop wpa_supplicant[257]: wlan0: Authentication with 34:2c:c4:72:40:47 timed out. Apr 8 13:31:04 laptop wpa_supplicant[257]: BSSID 34:2c:c4:72:40:47 ignore list count incremented to 3, ignoring for 60 seconds Apr 8 13:31:04 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED bssid=34:2c:c4:72:40:47 reason=3 locally_generated=1 Apr 8 13:31:04 laptop wpa_supplicant[257]: BSSID 34:2c:c4:72:40:47 ignore list count incremented to 4, ignoring for 120 seconds Apr 8 13:31:04 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-DSCP-POLICY clear_all Apr 8 13:31:07 laptop wpa_supplicant[257]: wlan0: Trying to associate with 34:2c:c4:72:40:40 (SSID='Lenhossek_3A_12' freq=5240 MHz) Apr 8 13:31:09 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:31:09 laptop kernel: rtw880: sta 00:45:e2:a5:15:1b joined with macid 0 Apr 8 13:31:09 laptop kernel: wlan0: link state changed to UP Apr 8 13:31:09 laptop wpa_supplicant[257]: wlan0: Associated with 34:2c:c4:72:40:40 Apr 8 13:31:09 laptop dhclient[277]: send_packet: No buffer space available Apr 8 13:31:09 laptop wpa_supplicant[257]: wlan0: WPA: Key negotiation completed with 34:2c:c4:72:40:40 [PTK=CCMP GTK=CCMP] Apr 8 13:31:09 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-CONNECTED - Connection to 34:2c:c4:72:40:40 completed [id=0 id_str=] Apr 8 13:31:13 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:31:15 laptop dhclient[4669]: New IP Address (wlan0): 192.168.0.54 Apr 8 13:31:15 laptop dhclient[4673]: New Subnet Mask (wlan0): 255.255.255.0 Apr 8 13:31:15 laptop dhclient[4677]: New Broadcast Address (wlan0): 192.168.0.255 Apr 8 13:31:15 laptop dhclient[4681]: New Routers (wlan0): 192.168.0.1 Apr 8 13:31:43 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:36:08 laptop kernel: wlan0: link state changed to DOWN Apr 8 13:36:08 laptop kernel: rtw880: sta 00:45:e2:a5:15:1b with macid 0 left Apr 8 13:36:08 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED bssid=34:2c:c4:72:40:40 reason=0 Apr 8 13:36:14 laptop wpa_supplicant[257]: wlan0: Trying to associate with 34:2c:c4:72:40:47 (SSID='Lenhossek_3A_12' freq=2437 MHz) Apr 8 13:36:24 laptop wpa_supplicant[257]: wlan0: Authentication with 34:2c:c4:72:40:47 timed out. Apr 8 13:36:24 laptop wpa_supplicant[257]: BSSID 34:2c:c4:72:40:47 ignore list count incremented to 5, ignoring for 600 seconds Apr 8 13:36:24 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED bssid=34:2c:c4:72:40:47 reason=3 locally_generated=1 Apr 8 13:36:24 laptop wpa_supplicant[257]: BSSID 34:2c:c4:72:40:47 ignore list count incremented to 6, ignoring for 1800 seconds Apr 8 13:36:24 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-DSCP-POLICY clear_all Apr 8 13:36:27 laptop wpa_supplicant[257]: wlan0: Trying to associate with 34:2c:c4:72:40:40 (SSID='Lenhossek_3A_12' freq=5240 MHz) Apr 8 13:36:29 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:36:29 laptop kernel: rtw880: sta 00:45:e2:a5:15:1b joined with macid 0 Apr 8 13:36:29 laptop kernel: wlan0: link state changed to UP Apr 8 13:36:29 laptop wpa_supplicant[257]: wlan0: Associated with 34:2c:c4:72:40:40 Apr 8 13:36:29 laptop dhclient[277]: send_packet: No buffer space available Apr 8 13:36:29 laptop wpa_supplicant[257]: wlan0: WPA: Key negotiation completed with 34:2c:c4:72:40:40 [PTK=CCMP GTK=CCMP] Apr 8 13:36:29 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-CONNECTED - Connection to 34:2c:c4:72:40:40 completed [id=0 id_str=] Apr 8 13:36:32 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:36:32 laptop dhclient[4718]: New IP Address (wlan0): 192.168.0.54 Apr 8 13:36:32 laptop dhclient[4722]: New Subnet Mask (wlan0): 255.255.255.0 Apr 8 13:36:32 laptop dhclient[4726]: New Broadcast Address (wlan0): 192.168.0.255 Apr 8 13:36:32 laptop dhclient[4730]: New Routers (wlan0): 192.168.0.1 Apr 8 13:36:43 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:41:29 laptop kernel: wlan0: link state changed to DOWN Apr 8 13:41:29 laptop kernel: rtw880: sta 00:45:e2:a5:15:1b with macid 0 left Apr 8 13:41:29 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED bssid=34:2c:c4:72:40:40 reason=0 Apr 8 13:41:35 laptop wpa_supplicant[257]: wlan0: Trying to associate with 34:2c:c4:72:40:47 (SSID='Lenhossek_3A_12' freq=2437 MHz) Apr 8 13:41:45 laptop wpa_supplicant[257]: wlan0: Authentication with 34:2c:c4:72:40:47 timed out. Apr 8 13:41:45 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED bssid=34:2c:c4:72:40:47 reason=3 locally_generated=1 Apr 8 13:41:45 laptop wpa_supplicant[257]: BSSID 34:2c:c4:72:40:47 ignore list count incremented to 2, ignoring for 10 seconds Apr 8 13:41:45 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-DSCP-POLICY clear_all Apr 8 13:41:48 laptop wpa_supplicant[257]: wlan0: Trying to associate with 34:2c:c4:72:40:40 (SSID='Lenhossek_3A_12' freq=5240 MHz) Apr 8 13:41:49 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:41:49 laptop kernel: rtw880: sta 00:45:e2:a5:15:1b joined with macid 0 Apr 8 13:41:49 laptop kernel: wlan0: link state changed to UP Apr 8 13:41:49 laptop wpa_supplicant[257]: wlan0: Associated with 34:2c:c4:72:40:40 Apr 8 13:41:49 laptop dhclient[277]: send_packet: No buffer space available Apr 8 13:41:49 laptop wpa_supplicant[257]: wlan0: WPA: Key negotiation completed with 34:2c:c4:72:40:40 [PTK=CCMP GTK=CCMP] Apr 8 13:41:49 laptop wpa_supplicant[257]: wlan0: CTRL-EVENT-CONNECTED - Connection to 34:2c:c4:72:40:40 completed [id=0 id_str=] Apr 8 13:41:57 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:41:58 laptop dhclient[4758]: New IP Address (wlan0): 192.168.0.54 Apr 8 13:41:58 laptop dhclient[4762]: New Subnet Mask (wlan0): 255.255.255.0 Apr 8 13:41:58 laptop dhclient[4766]: New Broadcast Address (wlan0): 192.168.0.255 Apr 8 13:41:58 laptop dhclient[4770]: New Routers (wlan0): 192.168.0.1 Apr 8 13:42:13 laptop kernel: rtw880: failed to get tx report from firmware Apr 8 13:44:13 laptop syslogd: last message repeated 1 times Apr 8 13:44:20 laptop syslogd: last message repeated 6 times Apr 8 13:48:25 laptop ntpd[4824]: ntpd 4.2.8p15-a (1): Starting ```
Thanks for your great work @Bjoern, my realtek wireless card, which has a different subvendor between ones on the support matrix, works fine now on 13.1-RC2. Hope we can get rid of the annoying "failed to get tx report from firmware" error messages assp patches applied to 13.1-rc2: 2774f206809b8fd3a4904fe945f029a414fbc642 73d4ebea3567f18db549638c3d897b6d6758faa4 20eeed6844e2ab82b909e02c720101297e78d916 3443476ca9e751cebbb1c467091551bf3d518814 86220d3cbd500b1018dcdabb0ba70644db438cfd 20220408-01-lkpi-skb-rtw88-4g.diff 9df5f29caf1a818999d0e908cab95c83bd1f4323 (kernel crash without this one) pcconf output: rtw880@pci0:1:0:0: class=0x028000 rev=0x00 hdr=0x00 vendor=0x10ec device=0xc822 subvendor=0x1058 subdevice=0x1e25 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8822CE 802.11ac PCIe Wireless Network Adapter' class = network dmesg output: rtw880: <rtw_8822ce> port 0x2000-0x20ff mem 0xd0500000-0xd050ffff at device 0.0 on pci1 rtw880: successfully loaded firmware image 'rtw88/rtw8822c_fw.bin' rtw880: Firmware version 9.9.10, H2C version 15 rtw880: start vif 80:30:49:cc:83:cb on port 0 wlan0: Ethernet address: 80:30:49:cc:83:cb lo0: link state changed to UP rtw880: sta 80:30:49:cc:83:cb joined with macid 0 wlan0: link state changed to UP ubt0 on uhub0 ubt0: <Bluetooth Radio> on usbus1 WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() rtw880: failed to get tx report from firmware ugen0.3: <Logitech USB Receiver> at usbus0 ums0 on uhub1 ums0: <Logitech USB Receiver, class 0/0, rev 2.00/22.00, addr 2> on usbus0 ums0: 16 buttons and [XYZT] coordinates ID=0 uhid0 on uhub1 uhid0: <Logitech USB Receiver, class 0/0, rev 2.00/22.00, addr 2> on usbus0 rtw880: failed to get tx report from firmware rtw880: failed to get tx report from firmware
Without 4G memory limits on 13.1-rc2. Once I clone freebsd-src from github or transfer some large files the connection will be broken. dmesg error: XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed rx routine starvation XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed
The results from my weekend session. It takes some time for the driver to detect and power on the wifi card. The inconvenience can be mitigated by loading the kernel module at `loader` stage and using `SYNCDHCP`. It still slows down the startup by a couple of seconds, it's bearable though. The connection state was fine, I did not observe any deviations from what Linux offers. I might suspect that connection snaps might be related to attempts to power save when laptop is idling, I observe non of them when actively using the hardware. The last (and honestly the least) is kernel spam: ``` kernel: rtw880: failed to get tx report from firmware ``` # /boot/loader.conf autoboot_delay="1" zfs_load="YES" if_rtw88_load="YES" vfs.root.mountfrom="zfs:rpool/freebsd" # /etc/rc.conf hostname="laptop.local" dumpdev="NO" keymap="pl.kbd" kld_list="i915kms" wlans_rtw880="wlan0" ifconfig_wlan0="WPA SYNCDHCP" moused_nondefault_enable="YES" ntpd_enable="YES" ntpd_sync_on_start="YES" dbus_enable="YES" sddm_enable="YES"
Bjoern, I'd like to thank you for the great job you did and are doing with implementing RTW88 support. If there's additional testing you'd like me to perform, I'd be glad to help.
(In reply to Hong Hao from comment #28) Hi, can you please try "main" (CURRENT) after 952643ea452655a8e80d1b5e1cc2cae35cb73870 [ https://cgit.freebsd.org/src/commit/?id=952643ea452655a8e80d1b5e1cc2cae35cb73870 ] or if you are on stable/13 chrry-pick at least that change (might be MFCed tomorrow if I find enough time but otherwise will be a few more days) and see if that improves the situation for you for the "XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed"?
I have a pending change in my tree to improve the logging but also to run a test for one of the two main "log noises" reported. I'll try to get that out soon as well. Should help us to understand the reports or we'll disable them in FreeBSD.
For everyone who is seeing either of these two: - failed to write TX skb to HCI - failed to get tx report from firmware can you please apply the patch from here (also linked on the wiki now): https://people.freebsd.org/~bz/wireless/20220417-01-rtw88-debug.diff For one it adds error codes and function name to the report so we can possibly find out where and more likely what is going wrong. For the other one it adds a bit so testing code given the current code also seems racy to avoid that race and in addition also adds more information about how severe the problem might be. Please report the outcome back here. -- Update Release to CURRENT as this driver will never see 12.x (hopefully 13.2-R and 14.0-R).
The latest kernel as of Mon Apr 18 with - 4GiB patch - https://people.freebsd.org/~bz/wireless/20220417-01-rtw88-debug.diff panics at boot. Same config as above. Please see the screenshot.
Created attachment 233297 [details] 2022-04-18-crash.png
(In reply to szubersk from comment #35) Is this main or stable/13 with backports? Can you confirm whether the kernel works without the 20220417-01-rtw88-debug.diff patch? Or can you get a crashdump and extract the full log or use show msgbuf in ddb to scroll through and show what is before the panic message we see here?
14.0-CURRENT with kernel compiled myself (due to 2 patches). I'll reinstall base.txz 187994644 2022-Apr-14 08:29 from scratch in a couple of minutes to check the status w/o said patch.
(In reply to szubersk from comment #37) base isn't really the issue; just kernel. The reason I was asking about main vs. stable/13 was that at that time there was a difference in code now yet MFCed which happened this morning. I am just wondering if 4b63d8489ecf29e1acc50f1466b22f529db61eee could be your issue but it was hard to say. If the panic doesn't go away you could try backing that single change out and see if that helps. I am just saying as I'll drop off later today for a day or two so you can go ahead and see. I am still hoping that it's something else :-)
And should it turn out to be the debugging patch you could reduce it to: https://people.freebsd.org/~bz/wireless/20220418-01-rtw88-debug.diff Sorry, many options to test. You'll find out which as you find out what causes the panic in first place.
Whenever I test I use the most recent (at the compilation moment) main kernel. For today's test I used whatever there were in main branch. I reverted the https://people.freebsd.org/~bz/wireless/20220417-01-rtw88-debug.diff and the panic went away. I'll test the other possibilities later on. Fun fact: I was able to load the module and ping cloudflare using vanilla kernel w/o 4gib patch. Unfortunately `pkg update` made the module croak and I lost connectivity to the wifi card. Reboot helped.
(In reply to szubersk from comment #40) Great, in that case the only thing to still try is the patch from comment #39 from today and you can ignore the comment #38. Keep the 4G patch on top in any case. Without it you may only be so blessed for a few operations but eventually it'll fail if it indeed starts; if you are still running without it and it fails you can check what `sysctl compat.linuxkpi.lkpi_pci_nseg1_fail` says (is it 0 or not)?
(In reply to Bjoern A. Zeeb from comment #41) https://people.freebsd.org/~bz/wireless/20220418-01-rtw88-debug.diff application makes the system operational but the log is still cluttered ``` Apr 18 16:13:37 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 4 Apr 18 16:13:37 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 117 Apr 18 16:13:37 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 2 Apr 18 16:13:48 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 293 Apr 18 16:14:07 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 472 Apr 18 16:14:07 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 274 Apr 18 16:14:18 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 255 Apr 18 16:14:18 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 21 Apr 18 16:14:18 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 146 Apr 18 16:14:37 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 130 Apr 18 16:14:37 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 3 Apr 18 16:14:37 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 111 Apr 18 16:14:37 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 115 Apr 18 16:14:37 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 6 Apr 18 16:14:37 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 155 Apr 18 16:14:37 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 2 Apr 18 16:14:48 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 109 Apr 18 16:14:48 laptop kernel: rtw880: failed to get tx report from firmware: txreport qlen 9 ```
(In reply to szubersk from comment #42) Thanks for posting the results. I'll disable the logging by default in the next update.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e140d551b78670fbf99c83a59438cb13de50420f commit e140d551b78670fbf99c83a59438cb13de50420f Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2022-04-27 15:20:34 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2022-04-27 15:20:34 +0000 rtw88: deal with debug messages The 'failed to write TX skb to HCI' error message is twice in the code. Print the function name and along with the message and also the reported error so it can possibly be helpful. The 'failed to get tx report from firmware' was purposefully changed away from debugging in the upstream Linux driver in 584dce175f0461d5d9d63952a1e7955678c91086 . Revert that decision and extend the logging by the actual queue length so we get an idea how sever the problem is (see PR for a report). PR: 248235 Sponsored by: The FreeBSD Foundation MFC after: 3 days X-MFC: only to get the reminder for later sys/contrib/dev/rtw88/tx.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
I just committed a change to freebsd/main (CURRENT) so you no longer need to patch your kernel but only set a tunable. You want to back-out the previous 4GB patch before updating and also put the following into loader.conf: compat.linuxkpi.skb.mem_limit=1 I updated the wiki page and sent an email to the freebsd-wireless list as well: https://wiki.freebsd.org/WiFi/Rtw88 https://lists.freebsd.org/archives/freebsd-wireless/2022-May/000500.html I will also MFC the driver soon to stable/13 for people to try there without having to manually cherry-pick changes anymore.
(In reply to Hong Hao from comment #28) (In reply to Bjoern A. Zeeb from comment #31) Hi, Bjoern. I'm on 13.1 RC6 with the latest sysctl tunable patch, wifi transmission is almost stable, except that I'm still getting "XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed" issue sometimes. As your suggestion https://cgit.freebsd.org/src/commit/?id=952643ea452655a8e80d1b5e1cc2cae35cb73870 has been cherry-picked. ``` May 7 04:16:21 freehom sendmail[12336]: unable to qualify my own domain name (freehom) -- using short name May 7 07:25:19 freehom kernel: rx routine starvation May 7 07:25:19 freehom kernel: XXX ERROR lkpi_80211_txq_tx_one: skb alloc failed May 7 07:25:22 freehom syslogd: last message repeated 6 times May 7 07:30:14 freehom syslogd: last message repeated 1 times May 7 07:40:14 freehom syslogd: last message repeated 133 times May 7 07:50:04 freehom syslogd: last message repeated 250 times May 7 08:00:15 freehom syslogd: last message repeated 549 times May 7 08:10:13 freehom syslogd: last message repeated 827 times May 7 08:20:13 freehom syslogd: last message repeated 697 times May 7 08:30:13 freehom syslogd: last message repeated 178 times May 7 08:40:13 freehom syslogd: last message repeated 114 times May 7 08:46:31 freehom syslogd: last message repeated 194 times ```
(In reply to Hong Hao from comment #46) Can you tell me which architecture this is and how much physical memory you have or post (or email me) a full dmesg (ideally from a verbose boot)?
(In reply to Bjoern A. Zeeb from comment #47) @Bjoern I have a huawei hornor laptop with Ryzen 4500u and 16G memory. I have sent you my full verbose dmesg output via gmail. %sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu|hw.physmem' hw.machine: amd64 hw.model: AMD Ryzen 5 4500U with Radeon Graphics hw.ncpu: 6 hw.physmem: 16477581312 hw.machine_arch: amd64
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=806f82499a35d020bc258b3a025cd78e6f93ea8a commit 806f82499a35d020bc258b3a025cd78e6f93ea8a Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2022-04-27 15:20:34 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2022-06-03 15:51:30 +0000 rtw88: deal with debug messages The 'failed to write TX skb to HCI' error message is twice in the code. Print the function name and along with the message and also the reported error so it can possibly be helpful. The 'failed to get tx report from firmware' was purposefully changed away from debugging in the upstream Linux driver in 584dce175f0461d5d9d63952a1e7955678c91086 . Revert that decision and extend the logging by the actual queue length so we get an idea how sever the problem is (see PR for a report). PR: 248235 Sponsored by: The FreeBSD Foundation (cherry picked from commit e140d551b78670fbf99c83a59438cb13de50420f) sys/contrib/dev/rtw88/tx.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=d3b0a58ee78ecdc5e2700e0aaaab21755496d148 commit d3b0a58ee78ecdc5e2700e0aaaab21755496d148 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2022-03-30 22:06:14 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2022-06-03 15:49:22 +0000 rtw88: import firmware for Realtek's rtw88 supported chipsets. Import the most recent versions of the firmware images for the rtw88 driver. This is based on linux-firmware at 681281e49fb6778831370e5d94e6e1d97f0752d6. rtw8822c firmware got downgraded in a later commit to 9.9.10: firmware version 9.9.11 added support for hw_scan and is reportedly causing more problems than 9.9.10 does. The license of the firmware matches the previous rtwnfw(4) firmware files (modulo a Copyright year) and you can find a copy in sys/contrib/dev/rtw88fw/LICENCE.rtlwifi_firmware.txt. Add build infrastructure to create the .ko files but do not yet hook it up to the build until all parts are in the tree. Approved by: core (imp) PR: 248235 (cherry picked from commit 73d4ebea3567f18db549638c3d897b6d6758faa4) (cherry picked from commit 3443476ca9e751cebbb1c467091551bf3d518814) .../dev/rtw88fw/LICENCE.rtlwifi_firmware.txt (new) | 39 +++++++++++++++++++++ sys/contrib/dev/rtw88fw/README (new) | 34 ++++++++++++++++++ sys/contrib/dev/rtw88fw/WHENCE (new) | 19 ++++++++++ sys/contrib/dev/rtw88fw/rtw8723d_fw.bin (new) | Bin 0 -> 28884 bytes sys/contrib/dev/rtw88fw/rtw8821c_fw.bin (new) | Bin 0 -> 138984 bytes sys/contrib/dev/rtw88fw/rtw8822b_fw.bin (new) | Bin 0 -> 150984 bytes sys/contrib/dev/rtw88fw/rtw8822c_fw.bin (new) | Bin 0 -> 200312 bytes sys/contrib/dev/rtw88fw/rtw8822c_wow_fw.bin (new) | Bin 0 -> 145224 bytes sys/modules/rtw88fw/Makefile (new) | 10 ++++++ sys/modules/rtw88fw/Makefile.inc (new) | 17 +++++++++ sys/modules/rtw88fw/rtw8723d/Makefile (new) | 6 ++++ sys/modules/rtw88fw/rtw8821c/Makefile (new) | 6 ++++ sys/modules/rtw88fw/rtw8822b/Makefile (new) | 6 ++++ sys/modules/rtw88fw/rtw8822c/Makefile (new) | 6 ++++ sys/modules/rtw88fw/rtw8822c_wow/Makefile (new) | 6 ++++ 15 files changed, 149 insertions(+)
Something went wrong with my RTL8821CE after system update today ( amd64/main-n256126-d7814015125e-dirty ) It stops receiving and sending packets after few minutes of network activity. Unfortunately nothing is looged on console, wlan interface is up but gateway is unpingable. Unfortunately linuxkpi wlan is not playing nic with wlandebug so I just tried set compat.linuxkpi.rtw88_debug_mask to 16 Last line logged before network failure was Jun 14 10:15:00 sigill kernel: recv C2H, id=0xff, seq=0x5f, len=18 Please let me know how I can debug it further
(In reply to oleg.nauman from comment #51) I have no 8821CE to test. Sorry for the problem. You can probably set the tunable to a large kernel msg buffer: kern.msgbufsize=1146880 in loader.conf, reboot. And then set the full set of debugging flags for rtw88 (without RTW_DBG_IO_RW). Alternatively using dtrace on the rtw88 module will work to log things. You may probably also want to #define LINUXKPI_DEBUG_80211 and turn on 0x1113 for now. And then please email me as much data you can get privately. The last line alone is probably not helpful.
(In reply to Bjoern A. Zeeb from comment #52) Sent Thank you
Triage: priority reduced, to the norm for non-security bug reports. bz@ would you like to clear the flag for merge to stable/12? With <https://wiki.freebsd.org/WiFi/Rtw88> now linked from draft release notes for 13.2, is anything to be added there? Thanks
(In reply to Graham Perrin from comment #54) No definitively not for 12. There's still things which need to be pushed which may fix other issues, so leaving this open please.
Team, I have an AMD64 machine with freeBSD 13.1 running, this is currently not recognizing the RTL8822CE 802.11ac PCIe Wireless Network Adapter, what is the url to download the driver for this? Thanks,
(In reply to Isaac from comment #56) https://wiki.freebsd.org/WiFi/Rtw88#FAQ has: Q: I am running 13.1-RELEASE but I cannot find the driver? In short. 13.1-RELEASE was not supported. You'll need 13.2, stable/13 or 14 (main).
(In reply to Bjoern A. Zeeb from comment #57) thanks for the information and the quick response, appreciate it.
Hi, I kind of lost track on rtw88 with recent focus on iwlwifi and stability. Can anyone confirm if rtw88 on 8822CE 8821CE works with 11a/b/g? 15/14/13/and 13.3 from RC1 should be fine for basic use? Oleg, has your issue been solved? I cannot remember at all... sorry.
(In reply to Bjoern A. Zeeb from comment #59) We even got word that RTL8723DE works. I believe at this point that rtw88 works enough (maybe not well enough) to say the chipsets are supported and ongoing work will bring n updates but we'll need more detailed bug reports about individual problems.
(In reply to Bjoern A. Zeeb from comment #60) No, it does not work well enough. Here is my very recent experience with installing FreeBSD 14.1-RELEASE on a Lenovo IdeaPad S145 (rtw_8821ce): Using a mini-memstick image, the installation failed at the point of network configuration. But fortunately, I could install FreeBSD by first selecting "Live System" in bsdinstall, then entering "# kenv compat.linuxkpi.skb.mem_limit=1", "# shutdown -p now" and turning on the machine and booting from the mini-memstick again and selecting "Installation". This time the network configuration worked and I could install the system. However, the second problem was, that the WLAN connection was not stable, e.g. when installing packages, suddenly I got a "-stalled-" status. After a reboot and managing to set up X and chromium, internet suddenly wouldn't work either after a while. A "ping 8.8.8.8" confirmed that there was no connection. I then realized that there was no setting "compat.linuxkpi.skb.mem_limit=1" in /boot/loader.conf on the installed system. So doing that and rebooting seems to give a stable connection now. So the problem is that the chip does not work at all during installation unless you first go to "Live System" in bsdinstall and do a "# kenv compat.linuxkpi.skb.mem_limit=1". After installation you still need to edit /boot/loader.conf manually. This is not satisfactory, taking into consideration that the mini-memstick (or the boot-only-iso) is meant to precisely have a working network connection right from the start.