Received mine today from ebay to replace an archer c7 v5. Followed the installation instructions and all went fine.
Reading the thread all this day waiting for the router to arrive, as i understand i need some tweaks for the 4 cores to balance the load. I enabled Software Offload, Packet Steering and placed this to the start up script. Am i ok?
I disabled my 802.11s + WPA3 config, and I still had the exact same wifi crash after about 6 hours.
I disabled software offload and made sure that packet steering was properly configured, and it wifi still crashed a number of hours later - same exact error.
Based on this experience I'm not writing WPA3 off yet. I remember someone in another post suggesting that the error (ar_wal_peer.c:2462 Assertion is_graceful_to_handle failedparam0 :zero, param1 :zero, param2 :zero.) might suggest some sort of incompatibility between the bdwlan.bin (upon which the board-2.bin is based) or cal...bin and the WLAN.HK.2.5.0.1 QC image.
Based on this speculation I went back to the OEM factory firmware and took a look. I can confirm that the board-2.bin from ipq-wifi-dynalink_dl-wrx36 contains the very same bdwlan.bin on my factory firmware. However, whereas the files in the OpenWrt ath11k-firmware-ipq8074 are WLAN.HK.2.5.0.1, the ones in the official firmware are WLAN.HK.2.3-02932-QCAHKSWPL_SILICONZ-1.384296.1.
I've now copied these over to my OpenWrt snapshot Dynalink and replaced those from ath11k-firmware-ipq8074.
After overwriting I've rebooted and the radios are both up and working - for now. It's only been up for an hour, so it's too early for me to know if this has made things better or worse.
Does anyone have any insights into why what I'm doing is either a good or a bad idea? Is there any reason to believe that the ath11k kernel drive will not play nicely with the 2.3.0 firmware?
This full load power consumption is specific of coremark, different router use will make different power consumption.
Using radios and eth ports will also increase power consumption.
I can't test/measure different loads, because I'm using the router.
Notes: Radios on, with one wifi client connected, but also idle.
Didn't look at temp. but I don't think it an issue.
Didn't compare latency, to see it performance gov. changes anything in my daily use.
Power meter #1 is accurate, 7W and 2W led lamps measure their exactly printed values.
Power meter #2 is not so accurate, 7W and 2W led lamps measure their exactly printed values, but oscillate 0.5W less a few times.
This mirrors my experiences with my previous R7800 where the differences in power consumption are negligible between governors. These routers have such nice heat sinks, thermals should never be an issue. Under full load is when the most current will pass through the processor, but even then it doesn’t appear to be much… and with the thermals so well in check, I just don’t see a reason not to run the performance governor 24/7 for those with higher bandwidths. Or even for those that don’t.
I think performance can give a bit higher than 0.1W power consumption difference with mixed cpu loads, when compared with other govs., because cpu clk will be fixed at a higher voltage step.
But looking at full load power consumption, looks like it's not much at all.
And from my days of computer over clocking, it’s not watts that kill chips, it’s amps (current). So as long as the current drops when idle (which id expect it to do), then longevity should not be affected whatsoever.
what is the process of updating the firmware of the device?
I see the option: "Upload a sysupgrade-compatible image here to replace the running firmware."
But nothing to scan and automatically upgrade, so that i know i am not flashing a wrong or incompatible file
I am running into issues since im using this router and want to make sure it's not solved by upgrading. I did not upgrade since i got the device around 1 and a half months ago.
Basically sometimes the whole connection is gone, using wireguard or not. rebooting does not help. And then it's solved again after it seems some random minutes.
EDIT: Maybe i need to open a other thread anyway to optimise my radio, i am not getting more then 250mbit next to the router with my wifi6 enabled galaxy s21 ultra.
It ran for over 12 hours on the WLAN.HK.2.3 firmware before it crashed with the same error.
Interestingly, 100% of the crashes coincide with a AP-STA-DISCONNECTED message.
Seems to me like the ath11k driver is sending an invalid request/message to the WLAN.HK.2.3 / WLAN.HK.2.5.0 firmware when a disconnect occurs.
# cat /tmp/list dump-log|sort|uniq|grep -f /tmp/list |grep '\(DISC\|fatal error received\)'
Sat Mar 11 07:28:51 2023 daemon.notice hostapd: phy1-ap1: AP-STA-DISCONNECTED a4:50:46:0f:3c:11
Sat Mar 11 07:28:51 2023 kern.err kernel: [43176.121616] qcom-q6v5-wcss-pil cd00000.q6v5_wcss: fatal error received:
Sat Mar 11 19:21:29 2023 daemon.notice hostapd: phy0-ap0: AP-STA-DISCONNECTED b8:94:e7:d5:6b:08
Sat Mar 11 19:21:29 2023 kern.err kernel: [42731.267073] qcom-q6v5-wcss-pil cd00000.q6v5_wcss: fatal error received:
Sun Mar 12 21:17:18 2023 daemon.notice hostapd: phy0-ap2: AP-STA-DISCONNECTED b8:94:e7:d5:6b:08
Sun Mar 12 21:17:18 2023 kern.err kernel: [91373.699929] qcom-q6v5-wcss-pil cd00000.q6v5_wcss: fatal error received:
Wed Mar 15 01:17:39 2023 daemon.notice hostapd: phy0-ap0: AP-STA-DISCONNECTED a8:db:03:96:80:84
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] qcom-q6v5-wcss-pil cd00000.q6v5_wcss: fatal error received:
I'm all ears if anyone has any ideas. @robimarko ?
Wed Mar 15 01:17:37 2023 daemon.notice hostapd: phy1-ap1: AP-STA-POLL-OK 48:e7:da:e0:d6:b5
Wed Mar 15 01:17:39 2023 daemon.notice hostapd: phy0-ap0: AP-STA-DISCONNECTED a8:db:03:96:80:84
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] qcom-q6v5-wcss-pil cd00000.q6v5_wcss: fatal error received:
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] QC Image Version: QC_IMAGE_VERSION_STRING=WLAN.HK.2.3-02932-QCAHKSWPL_SILICONZ-1.384296.1
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] Image Variant : IMAGE_VARIANT_STRING=8074.wlanfw.eval_v2Q
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936]
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] ar_wal_peer.c:2238 Assertion 0 failedparam0 :zero, param1 :zero, param2 :zero.
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] Thread ID : 0x00000069 Thread name : WLAN RT0 Process ID : 0
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] Register:
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] SP : 0x4c2883a8
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] FP : 0x4c2883b0
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] PC : 0x4b19bce0
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] SSR : 0x00000008
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] BADVA : 0x00020000
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] LR : 0x4b19b47c
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936]
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] Stack Dump
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] from : 0x4c2883a8
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936] to : 0x4c288c38
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.642936]
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.690535] remoteproc remoteproc0: crash detected in cd00000.q6v5_wcss: type fatal error
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.712544] remoteproc remoteproc0: handling crash #1 in cd00000.q6v5_wcss
Wed Mar 15 01:17:39 2023 kern.err kernel: [41134.720817] remoteproc remoteproc0: recovering cd00000.q6v5_wcss
Wed Mar 15 01:17:39 2023 kern.info kernel: [41134.753297] remoteproc remoteproc0: stopped remote processor cd00000.q6v5_wcss
Wed Mar 15 01:17:40 2023 kern.warn kernel: [41134.994495] ath11k c000000.wifi: failed to transmit frame -108
Wed Mar 15 01:17:40 2023 kern.warn kernel: [41134.994548] ath11k c000000.wifi: failed to transmit frame -108
Wed Mar 15 01:17:40 2023 kern.warn kernel: [41135.090955] ath11k c000000.wifi: failed to find peer a8:db:03:96:80:84 on vdev 2 after creation
Wed Mar 15 01:17:40 2023 kern.warn kernel: [41135.091012] ath11k c000000.wifi: failed to find peer vdev_id 2 addr a8:db:03:96:80:84 in delete
Wed Mar 15 01:17:40 2023 kern.warn kernel: [41135.098482] ath11k c000000.wifi: failed peer a8:db:03:96:80:84 delete vdev_id 2 fallback ret -22
Wed Mar 15 01:17:40 2023 kern.warn kernel: [41135.107171] ath11k c000000.wifi: Failed to add peer: a8:db:03:96:80:84 for VDEV: 2
Wed Mar 15 01:17:40 2023 kern.warn kernel: [41135.116212] ath11k c000000.wifi: Failed to add station: a8:db:03:96:80:84 for VDEV: 2
Wed Mar 15 01:17:40 2023 daemon.notice hostapd: phy0-ap2: STA a8:db:03:96:80:84 IEEE 802.11: Could not add STA to kernel driver
Wed Mar 15 01:17:40 2023 kern.warn kernel: [41135.161280] ath11k c000000.wifi: failed to update rx tid queue, tid 0 (-108)
Wed Mar 15 01:17:40 2023 kern.warn kernel: [41135.161326] ath11k c000000.wifi: failed to update reo for rx tid 0: -108
Wed Mar 15 01:17:40 2023 kern.info kernel: [41135.167406] phy0-ap0: HW problem - can not stop rx aggregation for a8:db:03:96:80:84 tid 0
Wed Mar 15 01:17:40 2023 kern.warn kernel: [41135.174130] ath11k c000000.wifi: failed to update rx tid queue, tid 0 (-108)
Wed Mar 15 01:17:40 2023 kern.info kernel: [41135.182189] phy0-ap0: HW problem - can not stop rx aggregation for a8:db:03:96:80:84 tid 4
Wed Mar 15 01:17:40 2023 kern.info kernel: [41135.189371] phy0-ap0: HW problem - can not stop rx aggregation for a8:db:03:96:80:84 tid 7
There are at least four different client devices. One is a Roku streaming stick. One is a Samsung Android, and I think that the others are Redmi Android phones.
Also, I would imagine that a disconnecting host has little to say to the QCA firmware, and whatever must be said is mediated by the ath11k driver. I could be wrong in that statement, as a lot of this ath11k stuff is a black-box to me.
I I don't like CPU being at max speed all the time and as you said min frequency doesn't have an effect while using perf gov.
My speed is 100/10 mbps VDSL2 that might become 200 vdsl or 500/1000 fiber, I also have transmission installed and a usb 2.0 to SCSI adaptor with a hard drive. Things that acher 7 couldn't handle anymore.
As has been explained already, it has nothing to do with that ancient firmware. I was grasping a straws when I tried that, because I was one of three people that had already reported the problem with the WLAN.HK.2.5.0.1.
You have been '@'d on all three of those reports, and had commented on the previous two.
This occurs on the very latest firmware, as I described in great detail in my original post.
I'm not counting "2.7.0" as "latest", as that is not what is included in the current snapshot.
