new warning incomin: also looks like the 6G radio cant report correct rates after the warning
everything still works tho
the warning is triggers by a nl80211 call. so from userspace. curious here. you show a line in calculate bitrate in mac80211. but your backtraces shows it in another function. again. in any way such warnings can be triggered by a client device which reports invalid nss settings. i have seen this with mobile phones and mediatek chipsets. i think i wrote a workaround for this in mac80211.
try this hack
and on top of this (just discovered, since i was not considering that the antenna setting is a mask instead of a count
this time i completely removed the 999-900-bss-transition-handling patch now the panic is simply gone, going just fine for two whole days
It still roams just fine from my basic testing unless you got a better way to test the bss transition.
I have 6 MX4300 (with nss) + 1 MX5500 (w/o nss) in the network under the same ssid as my setup.
MR7500 has both internal 5G and pcie 6G enabled with the exact same ssid as the others.
another fun fact: Qualcommax NSS Build - #4028 by umf137
this guy removed that same patch and issues r resolved for him
from his log it looks like the exact same issue i was having
1 Like
then you will get another crash bug if you roam between ssid. this will fix nothing. mine works fine. no crash. and its been used by others without crash in openwrt too. but i cannot talk for qosmios own modifications. i hintet already multiple changes i never made
the issue from umf137 you are refereing to is 5 months ago. this issue doesnt exist anymore. but you said you reverted the crashfixes. so no questions here
and to trigger now crashes. you need todo the following. create 2 vaps on 2.4 and 5 ghz. name the ssid identical on 2.4 and 5 ghz. and do something else with the other vaps's. this will bring you in trouble while using it.
the transition fix affects only chipsets where multiple radios are running on the same chipset. which affects only 2.4 and 5 ghz here
ye i honestly think its one of his changes he made when he updated and refreshed ur patches.
that makes more sense
should hav been more specific in the commit message about what is being fixed
i see, im happy with how 6G works now, so i'll worry about that later
if you have followed the thread before i submitted the transition fix you can find the crashlogs before i introduced a solution. you can also find other openwrt forum posts about ath11k crashes. i had the same problem on my side and found the issue later based on all these forum reports and developed this solution. the point is that the original code stores all peer addresses in one big hash table. with all i mean "all" no matter if 2.4 or 5 ghz interface on the same chip. if you now roam between these interfaces. it works in a way that your associate to a new interface before your disassoc on the old one. so a new hash is added, then then the disassoc comes and the hash is removed again and does not exist anymore. but the wifi firmware still knows about this client
and then it happens that simply the wifi firmware crashes. this is the symptom you will see. so in this case you will not see a kernel crash, but a wifi firmware crash.
so the kernel maintainers introduced a workaround for this shit handling of peers with the result that this roaming handling did not work anymore. so you cannot switch between these interfaces and it also caused other curious racy symptoms which leaded again to firmware crashes (i think this was related if you have multiple vaps running, but has the same root of the problem)
anyway. the fix splits the peer hash table to handle it individual for each interface. and not global for all interfaces.
this however here will not affect the pci interface since the pci interface has just one physical interface unlike the ahb bus on 6018
in addition my patch does of course remove this shit workaround from the kernel maintainers
here in this thread you can find logs of such firmware crashes
2 Likes
Any update to this? Last update was over 2 weeks ago: https://github.com/PIPIPIG233666/openwrt-ipq/releases/tag/r28887-764ac864e26
Re: My previous post reporting router crash when USB drive plugged in. I dont know how to capture logs on this, but the same router with dd-wrt on it and the same ext HDD, does not crash when the drive is connected to the router, and in fact, samba network shares, and DLNA media streaming of 4K video to a UHD player work from the drive connected to the MR7500 with dd-wrt.
