09:08 <f00b4r0> nbd: ping: is there anything else I can provide related to the mt7915 bug? I've kept the device running and one thing I forgot to mention is that this time there's no high cpu usage from napi/phy

09:27 <nbd> not at the moment. i need to spend more time looking into this

09:32 <mrkiko> nbd: if you happen to look at issue 859, the thing is that gl.Inet GL-MT6000 seems slower than expected on 2.4 ghz when not using AX technology, people reporting a cap of 100 mbit or so. I don't know if this is a problem or to be expected. In their fork of OpenWrt, gl.iNet used mt76 at some point, but then switched to mtk drivers to fix that.

09:33 <mrkiko> nbd: the device is mt7986 based, and the wi-fi subsystem is the builtin-wmac in dual mode, 4x4. That's the background of the story. I have the hw if testing is required.

09:34 <nbd> did you reproduce the issue yourself?

09:34 <mrkiko> nbd: I'm just telling this to give you the background of the GH issue itself, in case it's not clear

09:34 <mrkiko> nbd: I don't remember but I think I did at some point. But then I haven't tough it was really an issue

09:35 <mrkiko> nbd: in my reduced knowledge of the thing, I tough that 802.11n implies no more than 100 mb or so when in 2.4 ghz

09:36 <mrkiko> nbd: however, the related gl.iNet forum thread makes me think the problem is widespread enough to not be difficult to reproduce for me or anyone else with hw

09:37 <nbd> 2.4 ghz is not limited to 802.11n, it can use 802.11ax

09:38 <mrkiko> nbd: sure, and when ax is enabled the hw works as expected. But the bug was open because people expected 802.11n (no AX) to go faster than 100 mbit

09:38 <mrkiko> nbd: I don't know if this is a reasonable expectation, to me is not

09:38 <f00b4r0> nbd: ok thanks. Feel free to ping me any time (though next week I'll probably afk most of the time). I'll keep the device up

09:39 <f00b4r0> by the way I just checked and about 20000s after the end of the backtrace I pasted on sprunge, this line appeared for each phy-ap tuple: phy0-ap1: failed to set key (2, ff:ff:ff:ff:ff:ff) to hardware (-12)

09:39 <nbd> f00b4r0: anything after the first MCU timeout is pretty much irrelevant, since the firmware has already crashed

09:39 <f00b4r0> actually each except phyN-ap0

09:39 <f00b4r0> ah ok

09:41 <mrkiko> nbd: and power related issues where experienced, and reported to be solved by ]https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/dd919e8f12af98fe61650e79bf169c84f783fdc6/autobuild_mac80211_release/package/kernel/mt76/patches/0004-wifi-mt76-mt7915-fix-txpower-issues.patch

09:41 <mrkiko> nbd: but I am under the impression this is already in-tree now

09:44 <mrkiko> nbd: but looking at the patch itself I guess I can very well be wrong, unless the problem has been solved differently

09:46 <nbd> the problem with that patch is the fact that it does multiple things and contains no explanation of what is fixed and how

10:05 <mrkiko> nbd: well, I don't feel the urgency to solve the issue in itself butif I canhelp, you know where to find me :)

10:10 <nbd> robimarko: pushed out the mac80211 6.6.15 update

10:14 <robimarko> nbd: Thanks

10:15 <robimarko> Did you squash the 6.5.13 and 6.6.15 updates?

10:16 <nbd> yes, and i changed the download back to tarball like before

10:16 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)

10:17 <robimarko> nbd: Thanks

14:29 <nbd> f00b4r0: ping

14:29 <f00b4r0> nbd: pong

14:30 <nbd> i just pushed a mac80211 fix to master which might help on your crashy device

14:30 <f00b4r0> ok, will try it now :)

14:30 <f00b4r0> thanks

14:31 <f00b4r0> Just to be sure: do I apply this on top of your branch's changes or do I hard reset to master?

14:32 <nbd> you can backport to the tree that you're using, on top of the other change

14:32 <f00b4r0> so cherry-pick that one commit, correct?

14:32 <nbd> yes

14:32 <f00b4r0> roger

14:55 <f00b4r0> nbd: deployed and fw_debug_wm enabled. Will let you know what happens. thanks!

18:23 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (96.7% images and 100.0% packages reproducible in our current test framework.)

18:32 <cmonroe> nbd: what was the symptom that led to the patch (mac80211: add a fix for racy drv_sta_rc_update calls) you pushed today? i've seen a few weird cases on MT7915/MT7986 where STAs associate and end up not doing any rate control in one direction.. usually they get stuck at a low MCS rate or smaller than available bandwidth and never adjust. disassoc/reassoc of the offending client fixes it. just curious if this patch may be related or if it was just

18:32 <cmonroe> a workaround for a crash :)

19:59 <nbd> cmonroe: i found hints in a mtk patch to mt76

20:00 <nbd> and that patch seemed like a workaround for a mac80211 bug, so i fixed mac80211 instead of applying the workaround

20:00 <nbd> no idea if there are non-crash symptoms to it

20:00 <nbd> but it's worth a try

22:24 <cmonroe> that makes sense.. I thought I saw something similar there.