amd-xgbe ("ax"): interface RX byte counter stays 0 (HWSTATS) — Reporting → Traffic shows no download
On a 10G WAN port driven by the AMD amd-xgbe driver (interface "ax"), the interface RX byte counter stays at ~0 even under several Gbit/s of inbound (routed) load, while TX is counted correctly. As a result Reporting → Traffic shows almost no "In" throughput even though the line is saturated. The data plane is fine — routing carries the traffic and a packet capture sees it — only the accounting is wrong. It looks like the driver advertises HWSTATS but never populates the RX hardware statistics.
Environment
OPNsense 26.4.1p2 (Business Edition)
NIC: AMD 10GbE — pciconf: ax1@pci0:8:0:5 vendor=0x1022 device=0x1458
Driver: amd-xgbe, version 1.0.3, firmware 16.118.33
Interface role: WAN, 10GBase-SFI, link up
At capture time: several Gbit/s inbound (download), ~60-80 Mbit/s outbound
Symptom
"In (bps)" under Reporting → Traffic is essentially flat (a few hundred bps), while "Out" and the pcap-based "Top hosts in" graph show real traffic. netstat confirms it, RX bytes stay at ~0 while TX is fine:
netstat -I ax1 -w 1 (WAN, under load) input ax1 output packets errs idrops bytes packets errs bytes colls 2 0 0 158 13340 0 7568812 0 1 0 0 64 11611 0 7484747 0 2 0 0 128 11775 0 7553285 0
~1-2 pkt/s and ~64-158 B/s inbound is physically impossible for a link doing multi-Gbit of routed traffic. The packets clearly arrive (routing works, tcpdump/iftop see them), they are simply not counted.
Evidence it is a counter issue, not the data path
sysctl dev.ax.1 — the driver's per-queue byte counters all read 0, including TX, which is demonstrably active at the iflib layer:
rxq_bytes[0..11]: 0 txq_bytes[0..11]: 0 ... dev.ax.1.iflib.txq00.txq_processed: 1187888204 (TX is flowing) dev.ax.1.iflib.txq00.r_enqueues: 1160571460 ... dev.ax.1.drv_info: driver: amd-xgbe version: 1.0.3 firmware-version: 16.118.33
ifconfig shows the HWSTATS capability set on the interface (IPs/MAC redacted):
ax1: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=4800028<VLAN_MTU,JUMBO_MTU,HWSTATS,MEXTPG> media: Ethernet autoselect (10GBase-SFI <full-duplex,rxpause,txpause>) status: active
My reading: because HWSTATS is set, the stack pulls the interface counters from the driver's hardware statistics instead of counting in software. The driver's RX hardware byte counter appears to stay at 0 (TX works), so if_ibytes never increments — hence the dead "In" graph.
Already ruled out
Suricata / IDS: never enabled on this interface.
Offloading: hardware checksum, TSO and LRO already disabled; VLAN hardware filtering disabled.
Not a routed-subnet / transfer-net artefact: that only affects the pcap-based top-talkers list; the plain interface byte counter is a separate mechanism.
Questions
Is this a known limitation of amd-xgbe in the current base, and is it fixed in 26.7 / FreeBSD 15.1?
Is there a supported way to make the stack fall back to software counting — e.g. is "ifconfig ax1 -hwstats" honoured by this driver, and can it be made persistent (and is it safe to toggle on a production link)?
Is anyone running a WAN on an "ax" port with correct Reporting → Traffic (RX) numbers?
Thanks in advance.
diagnostics are from my own box, write-up is AI-assisted — happy to post more output.
Is the cpu being fully offloaded to the NIC now?
You can try disabling this feature for individual NIC functions using sysctl.
Or use ifconfig ax1 -tso4 -tso6
So 1st try that.
To me it just sounds like a driver issue.
Quote from: BrandyWine on September 16, 2026, 01:05:34 AMIs the cpu being fully offloaded to the NIC now?
You can try disabling this feature for individual NIC functions using sysctl.
Or use ifconfig ax1 -tso4 -tso6
So 1st try that.
To me it just sounds like a driver issue.
@BrandyWine thanks for the input.
TSO is already disabled on this interface.
The ifconfig ax1 output in the original post only shows:
Is the cpu being fully offloaded to the NIC now?
so neither TSO4 nor TSO6 is currently enabled. Checksum offloading and LRO are disabled as well.
That is also why I'm leaning more towards a driver/counter issue at this point. The interesting part is that inbound traffic is clearly present on ax1 in packet captures and is routed normally, while if_ibytes and the driver's RX byte counters essentially stay at zero.
TX accounting works.
The remaining thing I'd like to test is disabling HWSTATS, e.g.:
ifconfig ax1 -hwstatsto see whether FreeBSD then falls back to software accounting and the RX counter starts increasing.
Do you happen to know whether -hwstats is properly supported by amd-xgbe / iflib, and whether toggling it on a live interface causes any interface reinitialization or traffic interruption?
Because I suppose it does.
Thx!
Tim :)
Quote from: ThomasE on September 14, 2026, 02:14:35 PMNIC: AMD 10GbE — pciconf: ax1@pci0:8:0:5 vendor=0x1022 device=0x1458
Driver: amd-xgbe, version 1.0.3, firmware 16.118.33
What is the
actual chip being used for this "AMD" NIC ?!
If it's Aquantia or RealTek and even Broadcom or Mellanox then you have got a great chance it's driver related and you need to talk to FreeBSD developers/maintainers about it :)
Quote from: nero355 on September 16, 2026, 06:08:33 PMIf it's Aquantia or RealTek and even Broadcom or Mellanox
That type of NIC is in the Desico appliances, like the DEC7xx or DEC8xx. It's from AMD and usually baked into the SoC.
Quote from: patient0 on September 16, 2026, 06:32:55 PMThat type of NIC is in the Desico appliances, like the DEC7xx or DEC8xx. It's from AMD and usually baked into the SoC.
OK, but is it this for example : https://www.amd.com/en/products/adaptive-socs-and-fpgas/intellectual-property/do-di-10gemac.html ?!
I am guessing the MAC is AMD and the actual chip does the PHY part ?!
man axp
[...]
DESCRIPTION
The axp driver enables PCI-E based 10G Ethernet controller inbuilt in the
AMD EPYC processors.
Quote from: nero355 on September 16, 2026, 11:24:11 PMOK, but is it this for example
I have no idea, I assume it's that but not sure.
The driver is maintained by AMD AFAIK but OPNsense made changes too since their boxes use it.
Need to look deeper.
Quote from: bot0x1458 is indeed the AMD EPYC integrated 10-GbE controller used by FreeBSD's axp driver. The important detail is that FreeBSD's driver was added as an iflib-based driver, and the hardware exposes separate RX DMA queues and management counters. If traffic works but RX counters remain at zero, this is likely a driver/statistics-path problem rather than PCI identification.
EPYC's do have various implementations of the PHY, but I see most (the newer stuff) use the axp driver. The pciconf shows a device ID that supposedly uses the newer AXP code, but technically still from the amd-xgbe module.
I suspect an iflib issue.
What AMD EPYC is it exactly?
https://cgit.freebsd.org/src/commit/?id=7113afc84c0
Quote from: BrandyWine on September 25, 2026, 01:12:45 AMEPYC's do have various implementations of the PHY
So maybe I was onto something ?
If so : COOL! :)
Quote from: patient0 on September 17, 2026, 06:54:38 AMQuote from: nero355 on September 16, 2026, 11:24:11 PMOK, but is it this for example
I have no idea, I assume it's that but not sure.
The driver is maintained by AMD AFAIK but OPNsense made changes too since their boxes use it.
Does this mean the freeBSD version in the OPNsense installer is a custom compiled version?
It would be much easier if the OS used KLM drivers making it much easier to swap them out.