Kernel panic with two dongles plugged in USB 3.0

[crgorect]

We have kind of an odd set up and are using this driver.

We have two Cudy AC1300 devices with the rtl8822bu plugged into a Raspberry Pi 4 64 bit Centos flavored linux and using NetworkManager. One Cudy is connecting to a network and the other is in AP mode. Modified config to set USB to 3.0 and vht auto enabled 2. Seems that we are getting quite a bit of different behavior with two plugged in compared to just one. The first being kernel panics (logs pasted below). I've disabled the USB 3.0 and the kernel panic goes away. In USB 2.0 mode nmcli says that the AP is being broadcasted, but it is not until we physically unplug/replug the dongle. Both odd issues that I wanted to bring to your attention. If any other information is needed feel free to reach out.

[ 20.880338] uart-pl011 fe201000.serial: no DMA platform data [ 21.029085] Unable to handle kernel paging request at virtual address ffffffc01145de50 [ 21.029141] Mem abort info: [ 21.029159] ESR = 0x96000007 [ 21.029179] EC = 0x25: DABT (current EL), IL = 32 bits [ 21.029205] SET = 0, FnV = 0 [ 21.029223] EA = 0, S1PTW = 0 [ 21.029241] Data abort info: [ 21.029258] ISV = 0, ISS = 0x00000007 [ 21.029279] CM = 0, WnR = 0 [ 21.029298] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000000d5b000 [ 21.029329] [ffffffc01145de50] pgd=00000000fbfff003, pud=00000000fbfff003, pmd=00000000f5c8e003, pte=0000000000000000 [ 21.032712] Internal error: Oops: 96000007 [#1] PREEMPT SMP [ 21.036144] Modules linked in: nft_counter ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_state xt_conntrack nf_conntrack nf_defrag_ipv4 nft_compat nf_tables nfnetlink rtc_ds1307 regmap_i2c ads7846 88x2bu(O) brcmfmac brcmutil bcm2835_codec(C) joydev bcm2835_isp(C) v4l2_mem2mem bcm2835_v4l2(C) sha256_generic libsha256 videobuf2_dma_contig evdev bcm2835_mmal_vchiq(C) cfg80211 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common rfkill raspberrypi_hwmon i2c_bcm2835 videodev mc vc_sm_cma(C) spi_bcm2835 rpivid_mem uio_pdrv_genirq uio sch_fq_codel i2c_dev ip_tables x_tables ipv6 nf_defrag_ipv6 crc_ccitt [ 21.060600] CPU: 3 PID: 498 Comm: RTW_CMD_THREAD Tainted: G C O 5.4.49-v8.1.el8 #1 [ 21.064255] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT) [ 21.067988] pstate: 60000005 (nZCv daif -PAN -UAO) [ 21.071931] pc : rtw_hal_write_bbreg+0x28/0x54 [88x2bu] [ 21.075708] lr : halwifionly_phy_set_bb_reg+0x3c/0x4c [88x2bu] [ 21.079426] sp : ffffffc01147ba60 [ 21.083226] x29: ffffffc01147ba60 x28: 0000000000000000 [ 21.087026] x27: 0000000000000024 x26: 0000000000000000 [ 21.090794] x25: 0000000000000000 x24: 0000000000000000 [ 21.094604] x23: 0000000000000001 x22: 0000000000000001 [ 21.098142] x21: 0000000000000300 x20: 0000000000000cbc [ 21.101511] x19: ffffffc011459000 x18: 0000000000000000 [ 21.105029] x17: 0000000000000000 x16: 0000000000000000 [ 21.108573] x15: 0000000000000000 x14: 0000000000000000 [ 21.112042] x13: ffffffc010e76000 x12: 0000000000000000 [ 21.115394] x11: 0000000000000000 x10: 00000000000019a0 [ 21.118755] x9 : ffffffc01147b660 x8 : ffffff80ea567340 [ 21.122188] x7 : 0000a8d6fdb4e812 x6 : 0000000000000001 [ 21.125700] x5 : ffffff80e98e0d80 x4 : ffffff80f79f7ce0 [ 21.129187] x3 : 0000000000000001 x2 : 0000000000000300 [ 21.132661] x1 : 0000000000000cbc x0 : ffffffc0091d9194 [ 21.136041] Call trace: [ 21.139469] rtw_hal_write_bbreg+0x28/0x54 [88x2bu] [ 21.142728] halwifionly_phy_set_bb_reg+0x3c/0x4c [88x2bu] [ 21.146020] hal8822b_wifi_only_switch_antenna+0x34/0x58 [88x2bu] [ 21.149243] ex_hal8822b_wifi_only_switchbandnotify+0x28/0x34 [88x2bu] [ 21.152447] hal_btcoex_wifionly_switchband_notify+0x58/0x5c [88x2bu] [ 21.155641] rtw_btcoex_wifionly_switchband_notify+0x20/0x2c [88x2bu] [ 21.158726] rtl8822b_switch_chnl_and_set_bw+0x40c/0x468 [88x2bu] [ 21.161633] rtl8822b_handle_sw_chnl_and_set_bw+0x1fc/0x200 [88x2bu] [ 21.164429] rtl8822b_set_channel_bw+0x54/0x68 [88x2bu] [ 21.167201] rtw_hal_set_chnl_bw+0xcc/0x154 [88x2bu] [ 21.169932] set_channel_bwmode+0x268/0x26c [88x2bu] [ 21.172694] site_survey+0x50/0x1bc [88x2bu] [ 21.175445] sitesurvey_cmd_hdl+0xa40/0xcf0 [88x2bu] [ 21.178169] rtw_cmd_thread+0x4ec/0x718 [88x2bu] [ 21.180852] kthread+0x124/0x128 [ 21.183556] ret_from_fork+0x10/0x18 [ 21.186281] Code: 2a0203f5 2a0303f6 aa1e03e0 d503201f (f9672a64) [ 21.189103] ---[ end trace 830809322120dce9 ]---

[morrownr]

I understand why the kernel panicked... I panicked while reading your post!

That is an interesting setup. Can I get you step back and explain the big picture to me. What is it that you are trying to accomplish? Repeater?

Some other info that could enhance this conversation:

Are you using hostapd to set up the AP?

Is the Centos a 64 bit variety?

I see that you are using rtw_vht_enable=2. Are you aware that this does good things for AP mode but terrible things for other modes?

My opinion: You might get a Pi going with two USB WiFi adapters in different modes if the adapters were based on different chipsets and used different drivers. Well, I do that here. Actually I have as many as 4 usb wifi adapters on one system at time but all adapters have different chipsets and use different drivers.

[crgorect]

It is something of a repeater that we are making as a part of one of products (not in the sense of any typical Linux bridging though). We are actually using two different dongle chipsets an 8822bu and an 8811cu. The problem being the 8811cu isn’t as performant so we are working on getting two of the 8822bu devices working and any insights would be great.

We are not using hostapd and went with NetworkManager as our application calls out and makes various commands to build out and set up the various things needed for the network and integrating with one tool was easier at the time then integrating with many tools. This is slowly, but surely changing as we build out richer feature sets.

The Centos version is of the 64 but variety.

I have actually been experimenting with vht set to 2 for a little bit today. Any insight into what problems that introduces to the other modes?

[morrownr]

My thoughts:

$ iw list

The above will show the following statement near the bottom:

"interface combinations are not supported"

That means the driver will not support more than one type of interface at the same time... and that is with one adapter.

What you are doing is going way beyond that by using two of same type of adapters. This driver is not built to support more than one adapter at the same time as far as I know. I've never even thought to try it but in thinking about it, the system is not built to support that... in any OS as far as I know.

My recommendation, if you are looking for another adapter that can support 867 Mb/s, is to get another adapter with that capability but uses a different chipset... the rtl8812au. I have a very good driver for the 8812au right here on this site:

https://github.com/morrownr

You can load multiple drivers supporting multiple USB adapters but the adapters need to have different chipsets. I do it here with up to 4.

Caution: Only use ( rtw_vht_enable=2 ) for the driver that is going into AP mode.

The adapters based on the MT7612u chipset have in-kernel support these days but I don't remember when that support first appeared. It is capable of 867 Mb/s.

Hopefully some of what I said helps.

Nick

[morrownr]

Good luck with your use case. If you need to reopen another issue, you are welcome to do so.