I’m trying to compile my custom OpenWrt image for an Intel Core Ultra 5 225F and I’m experimenting with these Target Optimization flags:
-O2 -pipe -march=arrowlake-s -mtune=arrowlake-s
-O2 -pipe -march=arrowlake -mtune=arrowlake
However, I’m getting issues specifically with LuCI: the web UI becomes sluggish or freezes, I get timeout errors, or applying settings sometimes hangs. Network speeds look fine, but the UI behavior is unstable.
In my build, the only changes I’m making are:
the Target Optimization flags,
drivers for a Realtek 8125 NIC and MT7922 Wi-Fi,
LuCI packages (SQM, hd-idle, UPnP, irqbalance, and Docker).
When I use the official generic OpenWrt x86_64 image from the OpenWrt downloads page, I don’t see any of these LuCI issues.
Additional context:
I build on Debian 13 with GCC 14.2.
OpenWrt’s toolchain uses GCC 14 as well.
I get the same behavior on OpenWrt 24.10.5 and 25.12.0-rc2.
What could I be doing wrong? Are those -march/-mtune targets correct for this CPU, or what would you recommend instead?
You have to diagnose on the system itself if something is miscompiled and crashes. Under very optimistic assumptions avx2 could be used for memcpy, kernel does not do heavy simd float processing to justify any change away from basic parameters.
Have you tried building without the optimization ? Just -march=x86_64 or only tried prebuilt ? I use -march=x86_64-v3 myself with glibc instead of musl.
Perhaps try completely wiping out the feeds folder rm -rf feeds and rebuild it with scripts/feeds update -a ; scripts/feeds install -a it’s a small chance, but it’s possible that a library binary is there from a previous build where maybe you used more risky compile flags. The scripts directory also can keep binaries around between builds.
The pragmatic approach would be, if it hurts, don't do it.
There is very little optimization would give you on x86_64, even less for 'typical router uses' (as in not multimedia type workloads).
Yes, there's probably a bug 'somewhere' that should be fixed, but you're probably the only one able and motivated to find and fix it…
Can you share your .config, so we can see, what you actually configured. The optimizations should not cause this, they are not respected by the kernel and in your other post your messages show a problem with nvme controller.
I'm sharing the .config file with you.
I also suspect the NVMe controller; I'm currently selecting kmod-nvme, but I'm not sure if it's the correct one or if I'm missing something else.
I guess one thing to think about is what might be different. What hardware are we talking about ? Are you passing through the network adapter(s) ? What type are the adapters ? If they are Realtek did you use the vendor driver or the standard r8169 driver ? Etc. If you are using the vendor driver (like r8125), use the mainstream driver (use r8169 instead) etc.
fgrep nvme ~/config
# CONFIG_PACKAGE_kmod-nvme is not set
# CONFIG_PACKAGE_libnvme is not set
# CONFIG_PACKAGE_nvme-cli is not set
Where did you enable kmod nvme?
The rest is pretty much the same as on my x86 build, which works on a N100.
I was finally able to resolve the issue. The problem turned out to be my NVMe SSD—the firmware it had was causing problems waking up from idle. After updating the firmware, the issue was completely resolved.
In case anyone else encounters this problem, my NVMe drive is a Samsung PM9C1a.
