Created attachment 302982 [details] dmesg output Using a vanilla 6.0.1 kernel compiled from sources for an arm32 (v7) platform with a QCN9074 WiFi card. The kernel panics a few seconds after the driver has been loaded and the interface set in monitor mode. Script used to setup interface: iw wlan0 set monitor control sleep 2 ip link set wlan0 up sleep 2 iw wlan0 set freq 5680 80MHz sleep 2 uname -a Linux BV1-26804 6.0.1-xilinx #1 SMP PREEMPT Wed Oct 12 09:15:44 UTC 2022 armv7l GNU/Linux lspci -mnn 00:00.0 "PCI bridge [0604]" "Xilinx Corporation [10ee]" "Device [7121]" "" "" 01:00.0 "Network controller [0280]" "Qualcomm [17cb]" "Device [1104]" -r01 "Qualcomm [17cb]" "Device [1104]" Using firmware from linux-firmware, commit fdf1a65258522edf18a0a1768fbafa61ed07e598 find /lib/firmware/ath11k/ -type f | xargs md5sum fcca36959c5f56f9f0fb7015083dc806 /lib/firmware/ath11k/QCN9074/hw1.0/m3.bin 668f53050a92db5b4281ae5f26c7e35d /lib/firmware/ath11k/QCN9074/hw1.0/board-2.bin 693ff3f4669e2c345c3a5446ca249406 /lib/firmware/ath11k/QCN9074/hw1.0/amss.bin
Also note that I tried to simply go to the place of the null exception and simply add a NULL check (see below), but then the kernel simply hangs later on some other calls. Looking at the code, I see this rx_desc is never assigned by kernel, it seems to me that those struct are just cast of some memory written by the firmware. Unfortunately, I don't have access to firmware source code, so I cannot dig further on this side. Becaus using the same kernel on an intel x64 works fine, I'm also starting to wonder whether this is related to using a 32bit platform. ath11k is quite recent, and maybe there hasn't been much tests on 32 bits platforms. NULL Check patch: --- a/components/ext_sources/linux/drivers/net/wireless/ath/ath11k/dp_rx.c +++ b/components/ext_sources/linux/drivers/net/wireless/ath/ath11k/dp_rx.c @@ -2456,7 +2456,7 @@ static void ath11k_dp_rx_deliver_msdu(struct ath11k *ar, struct napi_struct *nap status->flag |= RX_FLAG_RADIOTAP_HE; } - if (!(status->flag & RX_FLAG_ONLY_MONITOR)) + if (!(status->flag & RX_FLAG_ONLY_MONITOR) && rxcb->rx_desc != NULL) decap = ath11k_dp_rx_h_msdu_start_decap_type(ar->ab, rxcb->rx_desc); spin_lock_bh(&ar->ab->base_lock);
Did this work in earlier versions? And if yes: which ones?
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #2) > Did this work in earlier versions? And if yes: which ones? No, I never managed to get this to work. On older kernel, I couldn't even load the modules because my platform only support one MSI vector.
Okay, than it's nothing I should track. Note: if you don't get any help here in a week or two, you might want to contact the maintainers by mail (but I optimistic that bugzilla will work in this case), as explained here: https://docs.kernel.org/admin-guide/reporting-issues.html
This commit in v6.3-rc1 should fix it: https://git.kernel.org/linus/950b43f8bd8a