Hey folks. If you have a Beryl7 - I modified @kyoto44 patch and threw together a makefile/repo to make it easier for folks to try the latest snapshot build with his fix for the TX path.
If you check out the rest of that repo it's pretty easy to use to cook up a build. 
This solves a real issue I found on this hardware.
Thanks for the patch. I just added a link in GL-MT3600BE Wiki page to this discussion.
Will you submit a PR to official mt76 repo ?
I’d be happy to add this patch back to that repo but the solution is not my own - I added this patch (based off of the one in that aforementioned thread) against the march 2026 mt76 commit on the latest OpenWRT snapshot. My problem with the mt76 HEAD is that it causes the cpu to lock up. I haven’t bisected where, but the last 77 commits on that repo aren’t stable. They all lock up the cpu when WiFi activity starts. I haven’t figured out why yet.
I see. FYI, you can find a list of mt76 master commit history here:
Some of the commit title has keyword like tx_retries. Maybe you can take a peek at those commits later.
I have a couple in a test 802.11s mesh and not seen any problems. I have not speed tested ap<=>client, only meshnode<=>meshnode.
Could you give a brief summary of what problem you are patching as without diving into your Github repo, it is not at all clear what it is you are patching and under what conditions you need it?
So the thing is, the latest openwrt snapshot works great without this patch for most stuff, but I ran some iperf3 tests and saw a problem.
On the stock snapshot (mt76 2026.03.21), 5 GHz EHT80 on ch36, with a Mac HE80 client sitting right next to it at -39 dBm / SNR 53 - basically a perfect link. No crashes, no resets, no disconnects, dmesg/logread totally clean. The giveaway was iwinfo: the AP's TX rate was pinned at 6.0 Mbit/s while RX was 1200.9 (HE-MCS11, 2ss). So RX negotiates fine, TX just refuses to rate up.
That points at the MT7990 mt76 AP-TX path specifically (the TXWI/SDO family - same area as issue https://github.com/openwrt/mt76/issues/1043). It's TX-only; the kernel and the link itself are rock solid.
That's probably also why your mesh testing looks clean: A meshnode <-> meshnode isn't hammering the AP-TX path the same way a client download does. If you want to see it, point iperf3 at a wireless client and watch the download number tank.
@kyoto44 's patch in my build is essentially forcing the host to fill the TXWI (reverting/working around commit 55218e636092) so it stops relying on the broken offload path. After patching + make mt76-rebuild + reflash, that download goes back up where it should be.
Is this really a device specific fix though ?
HAH! @frollic 
Its a device specific fix in so far as I have a beryl7 and I cooked a build for myself and my device 
Technically you're right though, I imagine this fix would work for any device where is_mt7990(&dev->mt76) is true 
- but I've only tested and attested @kyoto44 's patch works for me. I don't have the hubris to purport that this fixes it for everyone when I'm not the original author and I haven't tested it for anything beyond what I have. And for what it's worth, my github repo just cooks a variant of @kyoto44's solution specifically for my device only on a pinned snapshot commit.
Don't take me wrong, I'm not being sceptical, I'm just trying to understand this as it is particularly relevant to a project I'm working on.
On my test mesh, there are people using it so with typical evening traffic, 2.4GHz EHT40, iw is reporting:
tx bitrate: 258.0 MBit/s
rx bitrate: 286.7 MBit/s
But it is a node to node path supporting at least one Youtube stream to one user and four other users doing browsing/social media stuff. It is hammering pretty hard.
(This is on a master/snapshot about 10 days old)
Why am I not seeing similar pinning to what you are seeing?
idk shrug - i was able to repro it myself on 5ghz EHT80 - i had 2.4ghz off - let me set up a precise repro tonight and you can try it too
That's actually the same as I posted in issue #1043. Anyways, it's just AI slop. And we need to wait until Mediatek finally fixes their firmware for mt799x family. or use patches from MTK openwrt feeds (wifi works well with WED enabled)
hey man! Why didn’t you try to upstream your patch? I absolutely saw it and used it along with some others as I was exploring all the latest patches for mt76. I completely agree we need some kind of more permanent solution. You’re the one who should propose it upstream - not me. I just chucked something together to easily cook it into a build for myself and posted here that it works for me and solves a blocker I had with this hardware. I felt like I was pretty clear about attributing the thread in my post but if you want more recognition I’m happy to add more. I am definitely not trying to claim authorship of your work.
So for the record the patch I posted is not my own and it comes from the thread I posted earlier - it solves a real issue I faced on this hardware and I wanted to report and share that with this fix things work better for me. I've made sure every single post here properly attributes you as the original author.
my problem with this openwrt mt76 repo is that its not stable - i tried using HEAD and it locks the CPU up. this patch from @kyoto44 solved my issue
Does this affect all MT76xx devices?
I have a couple of Beryl 7s (mt3600be) and cannot replicate this issue. I'm still waiting for the OP to give more details.....
Set up: Beryl 7 on latest OpenWrt SNAPSHOT
On the AP: apk update && apk add iperf3
Start iperf3 server on AP: iperf3 -s -D --pidfile /tmp/iperf3.pid
On the AP, find the AP interface name (Look for phy0.1-ap1 (or similar) running EHT80): iwinfo | grep -B1 "Mode: Master"
Start a TX rate sampler on the AP: while true; do echo "$(date +%H:%M:%S) $(iwinfo phy0.1-ap1 info | grep 'Bit Rate')"; sleep 1; done | tee /tmp/tx_rate_stock.log
On the client (Mac), run a 60s download test: iperf3 -c <ap_ip> -t 60 -R
Observe TX rate in the sampler log: TX rate drops to 6.0 MBit/s intermittently during the test.
eg:
03:13:19 Bit Rate: 404.3 MBit/s
03:13:21 Bit Rate: 404.3 MBit/s
03:13:22 Bit Rate: 6.0 MBit/s <-- BUG
03:13:23 Bit Rate: 404.3 MBit/s
I just confirmed the bit rate still drops on the latest snapshot:
OpenWrt: SNAPSHOT r35026-8ebf189e60
Kernel: 6.18.35 (built Jun 22 11:02:07 2026)
mt76 source: dated 2026-03-21 (commit 018f6031)
DISTRIB_REVISION: r35026-8ebf189e60
25.12.5 stable release is now available for Beryl 7. I suppose the same bug you've encountered is also in the stable branch too?
possibly - i'm not in a place to test it out i'm dogfooding my own patches while traveling