Any idea what happened to one of my units? I wanted to redo it with the new initramfs and now I get no WiFi at all no matter which build I check. If the WiFi dead?
[ 0.526428] mtk-pcie-gen3 1fc00000.pcie: host bridge /soc/pcie@1fc00000 ranges:
[ 0.534546] mtk-pcie-gen3 1fc00000.pcie: MEM 0x0020000000..0x0023ffffff -> 0x0020000000
[ 0.650043] mtk-pcie-gen3 1fc00000.pcie: x2 mode enabled
[ 0.655897] mtk-pcie-gen3 1fc00000.pcie: x2 mode: sister MAC mapped
[ 2.879927] mtk-pcie-gen3 1fc00000.pcie: x2: link not up after init, skipping speed check
[ 2.888914] mtk-pcie-gen3 1fc00000.pcie: x2: init complete, PERST deasserted
[ 2.996668] mtk-pcie-gen3 1fc00000.pcie: PCIe link down, current LTSSM state: detect.quiet (0x1)
[ 3.008348] mtk-pcie-gen3 1fc00000.pcie: probe with driver mtk-pcie-gen3 failed with error -110
[ 3.018289] mtk-pcie-gen3 1fc40000.pcie: host bridge /soc/pcie@1fc40000 ranges:
[ 3.026367] mtk-pcie-gen3 1fc40000.pcie: MEM 0x0028000000..0x002bffffff -> 0x0028000000
[ 3.569954] mtk-pcie-gen3 1fc40000.pcie: PCIe link down, current LTSSM state: detect.quiet (0x1)
[ 3.581640] mtk-pcie-gen3 1fc40000.pcie: probe with driver mtk-pcie-gen3 failed with error -110
EDIT: Never mind, it was a power issue. I use a USB-C to DC barrel jack with forced 12v PD and connected it do a power supply that was not giving me enough juice. Strange that instead of crashing or something it just would not initialize WiFi cards.
The 1/26 builds predate the debugfs change, so if you want to look at offload stats, you can use those.
The 1/26 builds are quite different regarding the NPU firmware and drivers, I think?
Anyway, I understand your choice, but I also want to point out that the original synthetic test (i.e., running iperf3 server and client through loopback) doesn’t quite reflect the real-world usage of this device. In most (if not all) cases, it is a router or a bridged AP, so any local sockets are out of the question. Since the kernel does a lot more work to handle local traffic than forwarded packets, the difference in performance with and without those debugfs options is likely exaggerated in the tests than during normal usage.
Plus, leaving these options as-is ensures better compatibility with the upstream and the packages from the official repository, and also avoids possible breakage like the luci-app-airoha-npu case.
Again, I understand your choice, and this is only a suggestion to improve compatibility. I deeply appreciate your hard work in bringing up this device and providing the builds.
Thanks, @TempestJunior. I was running into the same issue with the minimal-npu package. No connection on any ports when setting up VLAN filtering on the default br-lan device. Created the new bridge with vlan filtering and all ports work as expected.
Seriously, thanks for all the working making this functional. Getting a working 6GHz device on OpenWrt has been eluding me for the past few years. Just some tips for anyone like me who finds this massive thread and tries to setup one of these:
tftp: I beat my head against the wall for an hour trying to do the initial flash of this thing, bringing back bad memories of the 80s with diskless workstations booting by tftp. The problem? It simply didn’t like my Ethernet adapter! I found an old 100Mbps USB dongle, and then flashed it, no problem. IDK what the problem was – maybe it can’t handle writing to flash at 1Gbps?
VLANs: I also spent several hours trying to get VLANs to work despite having a known, working VLAN setup on 6 other OpenWrt devices. The problem? Apparently you have to reboot it after the initial VLAN setup (at least for the one br-lan is going to use)… but really, who is brave enough to reboot with a config that just failed that Luci just rolled-back? After that, I was able to add or remove other VLANs w/o rebooting.
I’ve been running for 2 days now. The performance is slightly below my MT6000, but I suspect that’ll get better with the latest NPU and mt76 updates. At the moment the only bit of strangeness is nothing has connected to its 2.4GHz radio! I haven’t figured out what to make of that yet – I had the same issues w/ a Dynalink. I’ve downgraded it to 801.11n and am waiting.
I update seamlessly to lumos-r33280, so I don't know what caused my previous upgrade bug.
I maybe have an trail, when I was on r33239 which denied to downgrade/upgrade, I couldn't install "crowdsec-firewall-bouncer", because it hanged in post install script, which added a nft rules.
The "nft add" command was hanging forever. Maybe broken nftables could prevent some services to stop/start correctly for flashing.
Trying to restart firewall services hanged too, because of nft commands.
For NPU firmware version not showing in lumos, you could update the "luci.airoha_npu" script that way :
local npu_fw="$(ls /lib/firmware/airoha/en7581*npu_rv32.bin 2> /dev/null || true)"
So it is compatible with the two versions "en7581_npu_rv32.bin" and "en7581_MT7996_npu_rv32.bin"
I have a github action that automatically rebases my branches against openwrt main. Sometimes these rebases fail, so for safety, I do it on the AUTO branch. I have another action that syncs up with the regular branches; this one is run manually.
I've got two units set up with a WDS link between them, trunking a couple of VLANs - initially I was using minimal, and bridge filtering appeared to work OK for me.
What I do have an issue with is, if I plug anything into the 10G ports (WAN or LAN2) it will pass traffic momentarily, before the following panic:
The device will then continue in a panic, reboot loop until I unplug the cable from the 10G port. I've tried a variety of 1G and 2.5G devices and all seem to cause it.
I've now switched to lumos-npu (to try the updated Realtek driver) and so far I've got a 2.5G device connected to the 10G LAN2 port and it's staying up. Will see how I get on over the next couple of days.
I’m experiencing a similar issue but on the WAN port (only) on all 3 Aps running minimal-r32811. In my case LAN2 works nicely and is trunk connected to 10G port of a backhaul switch. WAN, LAN3, LAN4 are access ports to 3 VLANs.
WAN port exhibits the issue you described above hence this port is currently not in use. LAN3 and LAN4 are very slow (probably 10M speed) despite being connected at 1G.
Reading your comment, it appears the issue is no longer reproducible on the recent lumo-npu-2026.03.02-r33282, is this the case?
It’s a custom build (I compile in a few extra packages, no code changes) but yes, the one I’m running now is based off that and I’ve got 2.5G devices connected to WAN and LAN2 without issue at the moment.
Oddly, my other device is still running minimal and that’s got a 10G connection to my fibre ONT on the WAN port and seems to have no issues.
At first I wondered if having the WAN port as part of the same bridge as LAN2/3/4 was the issue but I tried removing WAN from the bridge and still got the panics on WAN and LAN2.
I’ve recently tested the lumos-npu build r33282, coming from minimal-oc/minimal-npu.
Unfortunately, my 10G ports lan2/wan are down with nothing much I can do.
The devices plugged into those ports are 2.5G, so I’m guessing this is the issue.
There is nothing in dmesg about the failure:
EDIT: The strangest thing just happened…
The 10G ports were not activated like I said with me plugging/unplugging the 2.5G wall port.
I tried another 2.5G device and the ports activated fine immediately.
Then I retried the original device right after - and it worked.
Power saving stuff? What could be happening there?
EDIT2:
Rebooted and retried, now jumpstarting it with another port doesn’t work.
Meh
Decided to test the 10G ports again today, with my local builds of both the lumos-npu (r33255-3694d6ddf8) branch and minimal-npu (r33245-0f59f2f3d0).
Used a script to trigger link speed changes on my PC, connected to the 10G port on the W1700K. Both builds eventually end up with a nonworking 10G after a while, happened much faster on the minimal-npu build but I’ve only tested once.
I originally disabled as many debug options as possible to optimize performance while being transparent to users with no loss of functionality.
However, as @hexchain points out, debugfs is necessary for proper functioning of luci-app-airoha-npu. Therefore, it has been re-enabled in the latest builds. The other debug options remain disabled.
Sounds like a good idea. When @tesf23 first mentioned it, I thought it would be worthwhile to add, but then @danpawlik and @glassdoor seemed to say the Realtek firmware patch addressed it. And then no one mentioned anything for a while, so I thought the issue was fixed.
At the very least this doesn't seem to hurt anything, just a little more thorough initialization upon plug-in, so shouldn't cause any weird regressions.
I don't go around plugging/unplugging so I don't notice these types of issues.
Another issue I’m seeing on my unit, no matter the build (lumos/minimal), is some instability in the wireless function.
I have 2.4G on channel 11 width 20Mhz, with sae-mixed in one SSID, working fine for all clients.
I have another SSID for 5G (channel 149 / 80Mhz, sae-mixed) and 6G (channel 93 / 160Mhz, sae) combined.
With the 5G/6G SSID and specifically 5G clients I’m seeing some weird instability or non-functioning internet depending on the number of clients connected.
Anyone experiencing something similar?
EDIT:
I upgraded to latest lumos with commit 2ea81b5 mentioned before.
My 10G port is still not functioning after reboot unless I jumpstart it by first plugging the yellow LAN ports.
This is a known issue. The current workaround is to reboot your device continuously until they work. They will stay working until you reboot. It only affects some devices.
