On 4/30/2025 7:34 PM, Balsam Chihi wrote:
Hello again,
sorry for the delay.
i did further debugging and the i found out that in
"drivers/net/wireless/ath/ath11k/pci.c",
"static void ath11k_pci_clear_dbg_registers(struct ath11k_base *ab)",
the "val = ath11k_pcic_read32" calls are causing the kernel crash.
by removing them the driver is working properly.
so to answer your questions :
@Baochen Qiang:
is this instruction causing the synchronous external abort? which src line is it pointing to?
the src line is "val = ath11k_pcic_read32(ab, PCIE_Q6_COOKIE_ADDR);"
and any "val = ath11k_pcic_read32" in "static void
ath11k_pci_clear_dbg_registers(struct ath11k_base *ab)".
Thanks for the information.
Just to confirm, so you are saying it worked when you skipped
val = ath11k_pcic_read32(ab, PCIE_Q6_COOKIE_ADDR) alone but
still keeping the rest of the register accesses in ath11k_pci_clear_dbg_registers()?
Or you removed some more register reads in that function? May be you can share the
code diff that worked for you.
@Vasanthakumar Thiagarajan:
i) Was this working before for you and broken recently or it has been
like this since you tried first?
the crash exists since began working on the project with the same hardware.
also earlier versions of openwrt has the same bug.
samething for Yocto kirkstone and scarthgap.
FYI, i use two different QCN9074 chps one from Compex and the other
from 8devices.
both chips behave the same device_id=0xFF and they both crash because
of this bug.
so had to load different board-2.bin (provided by comprex and
8devices) for each WLAN device to have 2.4GHz and 5GHz bands.
default board-2.bin (provided by linux-firmware) did not resolve the
kernel crash.
ii) Running into same issue during rmmod of ath12k driver instead of
reboot?
both rmmod and reboot of the ath11k_pci driver cause the crash
iii) Is it possible to attach the console log during reboot also?
rmmod and reboot are the same logs i already shared above
ath12k logs during reboot showing register read values
in ath11k_pci_clear_dbg_registers() will be helpful which
was not there in your log.
Vasanth
