Amazon recently offered a great deal on the AK34 Mini PC that was too good to pass up. I had been looking for a router for my home network with a little more horsepower for Cloudflare Zero Trust and functionality for multiple VLANs. OPNsense seemed like a perfect fit for my needs.
The OPNsense install guide was very straightforward and I was up and running in no time at all. I chose to use use ZFS over the whole disk and wipe out the pre-installed version of Windows 10 Home Edition. The included mSATA drive does not support TRIM so additional workarounds are needed with UFS to avoid the dreaded SEND_FPDMA_QUEUED DATA SET MANAGEMENT errors.
Network Performance
I was quickly disappointed because some quick speed tests showed my new router was underperforming a four year old Linksys router by a lot. Some prior experience with FreeBSD has taught me that the included Realtek NIC drivers are terrible and suffer from a variety of issues.
A quick visit to System > Firmware > Plugins showed a package for the official Realtek driver os-realtek-re. The driver also needs a small change to the configuration to load at boot time. This was done by creating the file /boot/loader.conf.d/if_re.conf with these two lines:
if_re_load="YES" if_re_name="/boot/modules/if_re.ko"
Phantom CPU usage
[Update: The issue with CPU usage appears to have been resolved in the latest OPNsense 23.1 release] The most puzzling aspect to this router was the consistent utilization of one CPU core. The OPNsense dashboard reported 25% CPU utilization when idle no matter what was going on. The system identified this as “system” CPU time but while digging in further, the command top -aSH showed there was a rogue ACPI kernel thread consuming the resources.
Troubleshooting the issue with OPNsense was a dead end, however, there was a lot of information available for ACPI issues in Linux. After booting a rescue USB that showed there was a constant stream of ACPI interrupts from /sys/firmware/acpi/interrupts/gpe0F.
Numerous articles later and I was able to decompile the ACPI bios used on the system. The method for the interrupt in question was completely empty!
root@OPNsense:~ # acpidump -dt > acpi.asl
root@OPNsense:~ # grep -A3 _L0F acpi.asl
Method (_L0F, 0, NotSerialized) // _Lxx: Level-Triggered GPE, xx=0x00-0xFF
{
}
I took a stab in the dark and just removed the method entirely. The ASL code would fail to compile without errors (even before my attempted fix) but iasl -f acpi.asl was able to force it to compile. The ouput AML was copied to /boot and this /boot/loader.conf.d/acpi.conf was added.
acpi_dsdt_load="YES" acpi_dsdt_name="/boot/ak34.aml"
The system rebooted fine with the new ACPI AML and the CPU usage was resolved!
Other optimizations
/boot/loader.conf.d/devcpu-data.conf
cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin"