dchard
7892
It is not too big of a deal for me, will load it and start testing it.
knacky
7893
I have been using gcc12 with -O2 on x86_64 and mt76 for two weeks now. Performance and stability are both legit.
That would be great, it worked fine in AP mode but will crash if you tried disabling the radios
dchard
7895
Wonder what is missing that crashes remoteproc like that... Some ath11k stuff again?
MOD: it crashes on boot:
[ 8.425135] ath11k c000000.wifi: qmi ignore invalid mem req type 3
[ 8.432582] ath11k c000000.wifi: chip_id 0x0 chip_family 0x0 board_id 0x292 soc_id 0xffffffff
[ 8.432631] ath11k c000000.wifi: fw_version 0x270784a5 fw_build_timestamp 2022-06-15 06:44 fw_build_id WLAN.HK.2.7.0.1-01701-QCAHKSWPL_SILICONZ-1
[ 11.262974] br-lan: port 1(eth1) entered blocking state
[ 11.263022] br-lan: port 1(eth1) entered disabled state
[ 11.267284] device eth1 entered promiscuous mode
[ 11.278263] nss-dp 3a001600.dp4 eth2: PHY Link up speed: 1000
[ 11.279077] br-lan: port 2(eth2) entered blocking state
[ 11.283005] br-lan: port 2(eth2) entered disabled state
[ 11.288387] device eth2 entered promiscuous mode
[ 11.295355] nss-dp 3a001800.dp5 eth3: PHY Link up speed: 1000
[ 11.298984] br-lan: port 3(eth3) entered blocking state
[ 11.303750] br-lan: port 3(eth3) entered disabled state
[ 11.309135] device eth3 entered promiscuous mode
[ 11.316164] nss-dp 3a001200.dp2 eth0: PHY Link up speed: 1000
[ 11.630385] pppoe-digi: renamed from ppp0
[ 12.337458] br-lan: port 2(eth2) entered blocking state
[ 12.337512] br-lan: port 2(eth2) entered forwarding state
[ 12.341887] br-lan: port 3(eth3) entered blocking state
[ 12.347064] br-lan: port 3(eth3) entered forwarding state
[ 12.352376] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 12.360265] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[ 13.031782] br-lan: port 4(wlan1) entered blocking state
[ 13.031835] br-lan: port 4(wlan1) entered disabled state
[ 13.036492] device wlan1 entered promiscuous mode
[ 13.041712] br-lan: port 4(wlan1) entered blocking state
[ 13.046077] br-lan: port 4(wlan1) entered forwarding state
[ 13.197579] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[ 13.492911] qcom-q6v5-wcss-pil cd00000.q6v5_wcss: fatal error received:
[ 13.492911] QC Image Version: QC_IMAGE_VERSION_STRING=WLAN.HK.2.7.0.1-01701-QCAHKSWPL_SILICONZ-1
[ 13.492911] Image Variant : IMAGE_VARIANT_STRING=8074.wlanfw.eval_v2Q
[ 13.492911]
[ 13.492911] :Excep :0 Exception detectedparam0 :zero, param1 :zero, param2 :zero.
[ 13.492911] Thread ID : 0x00000069 Thread name : WLAN RT0 Process ID : 0
[ 13.492911] Register:
[ 13.492911] SP : 0x4bfacdc0
[ 13.492911] FP : 0x4bfacdd8
[ 13.492911] PC : 0x4b18d338
[ 13.492911] SSR : 0x00000001
[ 13.492911] BADVA : 0x009c9d7e
[ 13.492911] LR : 0x4b18d2b8
[ 13.492911]
[ 13.492911] Stack Dump
[ 13.492911] from : 0x4bfacdc0
[ 13.492911] to : 0x4bfad400
[ 13.492911]
[ 13.539442] remoteproc remoteproc0: crash detected in cd00000.q6v5_wcss: type fatal error
[ 13.561697] remoteproc remoteproc0: handling crash #1 in cd00000.q6v5_wcss
[ 13.569834] remoteproc remoteproc0: recovering cd00000.q6v5_wcss
[ 13.602516] remoteproc remoteproc0: stopped remote processor cd00000.q6v5_wcss
[ 14.408293] nss-dp 3a001400.dp3 eth1: PHY Link up speed: 1000
[ 16.328013] ath11k c000000.wifi: failed to find peer 9c:9d:7e:55:18:5b on vdev 1 after creation
[ 16.328073] ath11k c000000.wifi: failed to find peer vdev_id 1 addr 9c:9d:7e:55:18:5b in delete
[ 16.335537] ath11k c000000.wifi: failed peer 9c:9d:7e:55:18:5b delete vdev_id 1 fallback ret -22
[ 16.344248] ath11k c000000.wifi: failed to vdev 1 create peer for AP: -2
[ 16.353263] ath11k c000000.wifi: failed to submit WMI_VDEV_DELETE_CMDID
[ 16.359988] ath11k c000000.wifi: failed to clear rx_filter for monitor status ring: (-108)
Can anyone explain me what it's GRO and how enable it? I see a lot of people talking about it but I have no clue of what it is.
kirdes
7898
Maybe you can try WLAN.HK.2.6.0.1-00861 as well?
sorry to been an ass again with my questions... no mischief on the following.. but arent't we trying to get a PR through .. if there is anything to test create a new branch and post the PR on the stable branch to openwrt and keep going going on a the test branch for the brave ones to test?
Ansuel
7900
robi is trying to get all the patch sent upstream..
we are sorting ath11k leak...
we are checking if nss-dp can be improved...
this target require a tremendous amount of hack... we are tying to reduce them as low as possible...
in the meantime you guys even have image from the github repo so...
6 Likes
dchard
7901
I tried it a couple months ago, it was also crashing...
What I am not sure about is how can it be that it works for Robi, and it crashes on my end? BDF differences maybe?
thx @Ansuel but for some (including me) it feels things are stable enough ... or on my ignorance you still need to upstream to kernel / ath11k to be accepted as a PR with openwrt?don't know the process hence the question
Ansuel
7903
the priority for now is getting the kernel patch accepted upstream/reworked in an acceptable state..
our blocking was ath11k for the leak...
now the block is ath11k pci that is still broken and is problematic for some SoC that have wifi 6GHz with pcie
2 Likes
yes but isn't that with the AX9000 ? eg the PCI issue...honestly I am running now the AX3600 and Dynalink with no issues regarding memory leaks for a few weeks - two day screenshot below for the ax3600 and similar behaviour with the dynalink
i honestly say forget about the xiaomi ax9000 i thrown out and sold it back in ebay (this was an international version)... so suggest to focus on the devices that are working imho
kk123
7906
Hi, my ax3600 seems to be running with high memory usage ~300M since last build 32 days ago. Just curious is something updated recently to improve memory bits? could it be my build config still needs tweaking?
root@OpenWrt:~# cat /etc/os-release
NAME="OpenWrt"
VERSION="SNAPSHOT"
ID="openwrt"
ID_LIKE="lede openwrt"
PRETTY_NAME="OpenWrt SNAPSHOT"
VERSION_ID="snapshot"
HOME_URL="https://openwrt.org/"
BUG_URL="https://bugs.openwrt.org/"
SUPPORT_URL="https://forum.openwrt.org/"
BUILD_ID="r19679+19-810eac8c7f"
OPENWRT_BOARD="ipq807x/generic"
OPENWRT_ARCH="aarch64_cortex-a53"
OPENWRT_TAINTS="no-all"
OPENWRT_DEVICE_MANUFACTURER="OpenWrt"
OPENWRT_DEVICE_MANUFACTURER_URL="https://openwrt.org/"
OPENWRT_DEVICE_PRODUCT="Generic"
OPENWRT_DEVICE_REVISION="v0"
OPENWRT_RELEASE="OpenWrt SNAPSHOT r19679+19-810eac8c7f"
kirdes
7907
I know, but there were a few ath11k updates since then, so there is a slight chance that it's not crashing anymore.
dchard
7908
I honestly say: forget about nagging the devs about upstreaming as you clearly have no idea how that works, especially on the kernel side. Just stop it. Nobody cares if you think it is "stable enough" as it does not need to meet your "standards". You are doing this every week, and it really starts to get annoying.
oh dear shall i respond or not ... no I will not ...
dchard
7910
Exactly the same: remoteproc crashes with WLAN.HK.2.6.0.1-00861 the same way it does with 2.7.0.1
Question is: how can it work for Robi then? Either something is different on the BDF side, or something is different on the wireless settings side. Hm... interesting.
