I've been literally trying to get 3 of these modules to work in x86 machine in openwrt vm for a few weeks. No matter what version of kernel i use, i couldn't get it to work in vm openwrt or debian. It seems to work in bare metal though how stable i didn't test. Finally i give up vm and decided to make it run on bare metal debian. Now i can't get multiple qcn9074 to work in bare metal together. If i plug just one into system it works but if multiple it doesn't work at all and i get errors in dmesg. After 3-4 years i can't believe we still can't get it to work properly and how crappy ath11k drivers are. Qualcomm employees frequently commits into ath11k codebase i see but we are still in this state. My question is, is there a way to get the closed source proprietary driver for this module or does it work fine compared to open source ones? I know thats another pita to get it to work but i don't know what else i can do. I have 3 expensive wifi module that can't work together in same system.
No, there is no way to get the proprietary driver.
The issue with multiple cards or even with AHB+PCI is that they are using the same QRTR instance ID and that will conflict.
However, for QCN9074 we are shipping a hack that should allow multiple cards to work:
Thanks. but this didn't work either. I tried 23.05 on a usb disk and booted it. It recognized 2 modules (i plugged 2) and on Network->Wireless, it displayed 2 of them but no matter what i did, i couldn't turn it on. Interface seems disabled.
When I tried to up interface, i got error.
root@OpenWrt:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP qlen 1000
link/ether a0:36:9f:4f:df:38 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
link/ether a0:36:9f:4f:df:39 brd ff:ff:ff:ff:ff:ff
inet6 fe80::a236:9fff:fe4f:df39/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether a0:36:9f:4f:df:3a brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether a0:36:9f:4f:df:3b brd ff:ff:ff:ff:ff:ff
6: eth4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether a8:a1:59:dd:d6:98 brd ff:ff:ff:ff:ff:ff
7: eth5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether a8:a1:59:dd:d6:97 brd ff:ff:ff:ff:ff:ff
16: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether a0:36:9f:4f:df:38 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 fd38:84cb:f854::1/60 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::a236:9fff:fe4f:df38/64 scope link
valid_lft forever preferred_lft forever
24: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether c4:93:00:3a:34:9a brd ff:ff:ff:ff:ff:ff
25: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether c4:93:00:3a:34:4e brd ff:ff:ff:ff:ff:ff
root@OpenWrt:~# ifconfig wlan0 up
ifconfig: SIOCSIFFLAGS: I/O error
root@OpenWrt:~# ifconfig wlan1 up
ifconfig: SIOCSIFFLAGS: I/O error
dmesg is full of below error.
ath11k_pci 0000:07:00.0: swiotlb buffer is full (sz: 2176 bytes), total 32768 (slots), used 32764 (slots)
and when i try to up interface it logs below.
[36222.181460] ath11k_pci 0000:04:00.0: failed to send WMI_PDEV_SET_PARAM cmd
[36222.181468] ath11k_pci 0000:04:00.0: failed to set ac override for ARP: -5
Further update. With 1 card plugged, the interface is up now.
So, it seems the patch didn't resolve this issue.
Also i saw below in dmesg. I have no idea what it means.
root@OpenWrt:~# dmesg | grep ath11k
[ 11.213721] ath11k_pci 0000:04:00.0: BAR 0: assigned [mem 0x70800000-0x709fffff 64bit]
[ 11.222998] ath11k_pci 0000:04:00.0: enabling device (0000 -> 0002)
[ 11.242525] ath11k_pci 0000:04:00.0: MSI vectors: 16
[ 11.248562] ath11k_pci 0000:04:00.0: qcn9074 hw1.0
[ 11.254274] ath11k_pci 0000:04:00.0: FW memory mode: 2
[ 11.927377] ath11k_pci 0000:04:00.0: chip_id 0x0 chip_family 0x0 board_id 0xa0 soc_id 0xffffffff
[ 11.937619] ath11k_pci 0000:04:00.0: fw_version 0x290c8569 fw_build_timestamp 2023-03-25 06:50 fw_build_id
[ 13.811022] ath11k_pci 0000:04:00.0: htt event 48 not handled
How much RAM do you have assinged to the VM?
This is not vm. It is bare metal and i used usb flash with 23.05 to boot. With vm i couldn't even get one to work.
Any chance you can add the QRTR tool to your build?
Sure but i dont know to do. I have only built custom openwrt image with 6.1 kernel.
Just make a folder called qrtr under package/utils and wget the Makefile, then you can select it via menuconfig
Thanks. I had the chance to look at it. I built custom openwrt image from 23.0.5 branch with qrtr as you said above. I have no idea what to do with it. modprobe qrtr and then? 1 qcn9074 card is plugged at the moment. Should i plug 2 of them and try?
No need to modprobe, but please just run qrtr-lookup with one card and then with 2 and post here
With one card plugged:
root@OpenWrt:~# qrtr-lookup
Service Version Instance Node Port
15 1 0 11 1 Test service
69 1 11 11 2 ATH10k WLAN firmware service
With 2 of them plugged:
root@OpenWrt:~# qrtr-lookup
Service Version Instance Node Port
15 1 0 11 1 Test service
69 1 11 11 2 ATH10k WLAN firmware service
15 1 0 14 1 Test service
69 1 14 14 2 ATH10k WLAN firmware service
But it says ath10k is it normal? Dmesg is again full of below.
[ 262.964113] swiotlb_tbl_map_single: 10054 callbacks suppressed
[ 262.964114] ath11k_pci 0000:07:00.0: swiotlb buffer is full (sz: 2176 bytes), total 32768 (slots), used 32763 (slots)
Ok, so the patch is doing what its supposed to do and you dont have a QRTR instance clash, its fine that it says ath10k FW services as they are using the same service ID.
Now, there swiotlb buffer is too small or there is a leak in the driver.
You can try increasing the number of swiotlb slabs via the swiotlb=<allowed slabs> in the kernel cmdline.
OK. What a sane value would to put there and do i need to rebuild image for that or is there a way without it?
In the bootlog, the current swiotlb allowed slabs should be listed.
I think that 64MB should be the default, so first check that.
I increased the value to 131072 and it worked. Maybe lower value will work as well didn't try. It seems openwrt x86 uses old grub so all i need was to add parameter /boot/grub/grub.cfg.
For the testing, both 2.4 Ghz and 5 hz ssids seems up in openwrt but i can only see 2.4 ghz one in my phone, no 5ghz ssid and i configured seperate ssid for each.
Did you choose a DFS channel by chance?
What is the output of
logread|grep hostapd | grep "phy-X" (replace X with the number of the 5 Ghz phy)
I don't recall choosing but it says DFS enabled. Should i change channel or what?
root@OpenWrt:~# logread|grep hostapd | grep "phy0-ap0"
Sun Oct 22 20:22:38 2023 daemon.notice hostapd: phy0-ap0: interface state UNINITIALIZED->COUNTRY_UPDATE
Sun Oct 22 20:22:38 2023 daemon.notice hostapd: phy0-ap0: interface state COUNTRY_UPDATE->HT_SCAN
Sun Oct 22 20:22:38 2023 daemon.notice hostapd: phy0-ap0: interface state HT_SCAN->DFS
Sun Oct 22 20:22:38 2023 daemon.notice hostapd: phy0-ap0: DFS-CAC-START freq=5520 chan=104 sec_chan=-1, width=2, seg0=114, seg1=0, cac_time=60s
Sun Oct 22 20:23:42 2023 daemon.notice hostapd: phy0-ap0: DFS-CAC-COMPLETED success=1 freq=5520 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5570 cf2=0
Sun Oct 22 20:23:43 2023 daemon.notice hostapd: phy0-ap0: interface state DFS->ENABLED
Sun Oct 22 20:23:43 2023 daemon.notice hostapd: phy0-ap0: AP-ENABLED
I changed the 5ghz channel to 36 and 100 both didn't work. It doesn't show up.
EDIT: 100 seems to be a DFS channel but it doesn't work anyway.
Can you share the exact cards you used?
QCN9074 works for sure as its present on Xiaomi AX9000 which is quite popular.