I'm working on troubleshooting an issue that's been popping up irregularly since deploying OPNSense on a Protectli VP3210 (both new to me). The device is set up to perform all DHCP, DNS, firewall, and routing duties for the home network behind it.
Approximately every 1-7 days the network starts acting up. The symptoms aren't always consistent, but so far have tended to fall into one of three categories:
1. Something that looks like a DNS issue. Attempts to resolve an address will usually time out first try, but then succeed immediately a few seconds later. If I connect to the upstream router and use the same resolver, everything is normal.
2. DHCP will stop working for some/all devices.
3. An online game I play regularly has trouble connecting to the game servers.
Regardless of the symptom, the workaround that resolves it (temporarily) is the same. Go to Interfaces -> Settings, uncheck "Disable hardware checksum offload", Apply, recheck the box, Apply again. Everything immediately starts working as it should. (This is why I assume this is a NIC issue.)
Doing some research, I see that it's not uncommon for people to have issues with the Intel i226-V NICs, something I missed when I chose the hardware. Based on what I read I've been playing with various tunables, rebooting as necessary:
dev.igc.0.fc=0
dev.igc.1.fc=0
dev.igc.0.eee_control=0
dev.igc.1.eee_control=0
net.isr.bindthreads=1
net.isr.maxthreads=-1
net.isr.dispatch=deferred
net.inet.ip.intr_queue_maxlen=3000
hw.pci.enable_aspm=0
So far nothing has made a difference. The other thing that seems to be done commonly with these NICs is to upgrade the NVM firmware, which I'll try if I have to but that's a bit intimidating. Anyone have any other ideas before I go that route?
UPDATE (2026-08-12):
This was ultimately resolved by reflashing the BIOS from coreboot to AMI. Protectli has apparently seen some similar issues with the VP3200 series as they did with the VP2440 which they responded to with a patch to coreboot. No patch has been made for the VP3200 series as of this writing.
ASPM is causing this for I226 devices and I am not aware that updating the NIC firmware fixes that.
If there is an updated BIOS for the Protectl, try that first. You can actually make that go away with ASPM off, but AFAIK, you can only disable this for the whole machine under OpnSense if the BIOS does not set it selectively for your NICs.
The global setting is by done setting the tuneable hw.pci.enable_aspm=0. You should probably also set dev.igc.X.eee_control=0 with X=0,1.
Hi there,
While having a look at this issue, I noticed a potential bug in the iflib code making an automatic reset in case of a TX hang impossible, a custom kernel has been published which resolves this (though likely not the final patch version). Would you mind installing this kernel to see if this changes anything about the issue?
# opnsense-update -zkr 26.1.10-iflib
The commit in question is https://github.com/opnsense/src/commit/8dd26e6351d72a53fab5d47a16d053d5f8648353.
If it's this issue, you should see "watchdog timeout" messages appearing in your dmesg/system log. After this, an automatic reset should recover connectivity. If this happens, can you share these logs?
Your description of the issue sounds similar to others, however, there are still a lot of gaps to fill. Most notably, do you always need manual intervention to fix the issue? or does it recover on its own? Is it always the same igc interface? What is the auto-negotiated link state at the time of failure (# ifconfig igcX)? If there's no auto-negotiation, what link speed did you set it to?
Also, and perhaps most importantly, can you share a snapshot of
# sysctl dev.igc.X (where X is the affected interface) after the failure?
Lastly, please do these tests with all default tunables. As far as I know, dev.igc.0.eee_control=0 will *enable* EEE.
Cheers,
Stephan
And I forgot to ask, since you mention that toggling offloading fixes it,
does
# ifconfig igcX down && ifconfig igcX up
also fix it?
Cheers,
Stephan
On the presumption that ASPM is contributing to the issue:
I don't know that ASPM can be reliably disabled on Protectli units, at least those running coreboot. The 'hw.pci.enable_aspm=0' sysctl has not worked for me. I spoke to them several months ago in a support ticket and was told that this is a common request on Reddit and they are looking into adding ASPM controls in coreboot but was not given any timeframe. In the same conversation I was told that EEE gets a bad rep and I should not worry about it. 🤷
For the time being we're dependent on them issuing targeted fixes as they did for the VP2440 (https://protectli.com/news/vp2440-coreboot-issue/).
---
Having said that I have also seen the DNS timeout on rare occasion on my V1410 but never thought twice about it (assumed it was a normal network glitch). I don't see any watchdog related messages in dmesg as of now.
All I know is that ASPM can be disabled globally or on a per-device basis. The latter normally needs BIOS or driver support, the former, AFAIK, does not.
I had freezing issues on my I226-V NICs on a Minisforum MS-01, the bug was fixed via a BIOS update. Also, there was this discussion of possible remedies: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279245
Quote from: tuto2 on July 01, 2026, 02:06:43 PMIf it's this issue, you should see "watchdog timeout" messages appearing in your dmesg/system log. After this, an automatic reset should recover connectivity. If this happens, can you share these logs?
Yeah, a lot of the stuff I've read indicates I should see interfaces flapping in the logs, but I haven't actually seen any evidence of that. There's no incidence of "watchdog" or "timeout" anywhere in dmesg or the month or so of system logs that have built up, and the only link state changes I see appear to correspond to when I uncheck/check the box and apply. So it's possible this is something else entirely.
QuoteYour description of the issue sounds similar to others, however, there are still a lot of gaps to fill. Most notably, do you always need manual intervention to fix the issue? or does it recover on its own? Is it always the same igc interface? What is the auto-negotiated link state at the time of failure (# ifconfig igcX)? If there's no auto-negotiation, what link speed did you set it to?
So far the issue hasn't ever sorted itself out without my intervention, but since I can't tell when it's happening other than by the symptoms, I can't say for sure that it doesn't happen more often and occasionally fix itself. For most of the life of this issue speeds were on auto-negotiate (typically WAN 2500 Full, LAN 1000 Full). A few days ago I switched everything to static 1000 Full; the issue has popped up again once or twice since then.
I'll remove the tunables since they don't appear to be doing anything for me anyway, and I'll do a bit more digging next time this happens and see if I can come up with something more concrete to provide. In particular, I'm also curious if just ifconfig down/up will resolve it.
Quote from: OPNenthu on July 01, 2026, 07:38:38 PMI don't know that ASPM can be reliably disabled on Protectli units, at least those running coreboot. The 'hw.pci.enable_aspm=0' sysctl has not worked for me. I spoke to them several months ago in a support ticket and was told that this is a common request on Reddit and they are looking into adding ASPM controls in coreboot but was not given any timeframe. In the same conversation I was told that EEE gets a bad rep and I should not worry about it. 🤷
I'm on coreboot, so that's interesting, thanks. And yeah, I noticed that disabling ASPM via the tunable didn't appear to have any affect on temperatures or anything, so I guess that tracks.
QuoteHaving said that I have also seen the DNS timeout on rare occasion on my V1410 but never thought twice about it (assumed it was a normal network glitch). I don't see any watchdog related messages in dmesg as of now.
When it happens for me, it's basically every DNS resolution that hasn't been made recently. It's hard to miss.
Quote from: meyergru on July 01, 2026, 09:18:08 PMAll I know is that ASPM can be disabled globally or on a per-device basis. The latter normally needs BIOS or driver support, the former, AFAIK, does not.
Yeah, unfortunately it doesn't look like the coreboot BIOS offers any configurability here, and I'm on the latest (only?) version for my hardware. May try switching to AMI BIOS at some point, but I'm not there yet.
Quote from: fornax on July 01, 2026, 02:09:53 AM3. An online game I play regularly has trouble connecting to the game servers.
Could also be an issue with the game and not OPNsense related in some cases !!
Have you configured Hybrid NAT and a Static-Port Rule for the specific Client ?
Quote from: nero355 on July 02, 2026, 04:23:27 PMHave you configured Hybrid NAT and a Static-Port Rule for the specific Client ?
I have, yes. Most of the time it works. Just occasionally I have to reset the NIC as described above.
Quote from: fornax on July 01, 2026, 09:47:37 PMQuote from: tuto2 on July 01, 2026, 02:06:43 PMIf it's this issue, you should see "watchdog timeout" messages appearing in your dmesg/system log. After this, an automatic reset should recover connectivity. If this happens, can you share these logs?
Yeah, a lot of the stuff I've read indicates I should see interfaces flapping in the logs, but I haven't actually seen any evidence of that. There's no incidence of "watchdog" or "timeout" anywhere in dmesg or the month or so of system logs that have built up, and the only link state changes I see appear to correspond to when I uncheck/check the box and apply. So it's possible this is something else entirely.
I wasn't referring to instances of "watchdog" or "timeout" in your historic logs, these messages should pop up as a result of installing the custom kernel. If this is the case, I'd like to know if you still have to intervene manually.
For what it's worth, no report I've read so far has mentioned any link flapping, this seems to happen entirely without link state changes, but it does seem to happen with autonegotiation speed degradation, hence my questions to establish a baseline (which is why the sysctl output is important as well).
Cheers,
Stephan
Quote from: tuto2 on July 07, 2026, 09:20:39 AMI wasn't referring to instances of "watchdog" or "timeout" in your historic logs, these messages should pop up as a result of installing the custom kernel. If this is the case, I'd like to know if you still have to intervene manually.
Ok, I misunderstood. I'll try installing that kernel tomorrow and we'll see what happens. For what it's worth, when the DNS-like issue popped up earlier I found that ifconfig down/up on WAN didn't do anything, but doing it on LAN did resolve it.
Maybe there will eventually be a fix for this: https://github.com/freebsd/freebsd-src/pull/2318
Quote from: meyergru on July 09, 2026, 11:10:48 PMMaybe there will eventually be a fix for this: https://github.com/freebsd/freebsd-src/pull/2318
Looking forward to trying this when available in OPNsense! Packet loss has been a constant companion, as are random stream disconnects, but interface statistics tell a different story (all clean).
🤞
Quote from: tuto2 on July 01, 2026, 02:06:43 PMWhile having a look at this issue, I noticed a potential bug in the iflib code making an automatic reset in case of a TX hang impossible, a custom kernel has been published which resolves this (though likely not the final patch version). Would you mind installing this kernel to see if this changes anything about the issue?
Has the 226's NVM been updated?
Before installing new kernel,
I would try (from ssh or in a start script)
ifconfig igc0 -rxcsum -txcsum -rxcsum6 -txcsum6
ifconfig igc1 -rxcsum -txcsum -rxcsum6 -txcsum6
should be no need to down/up the device
Then monitor.
Offloading puts the function into hardware.
Disabled or not, iflib sits between kernel and driver. So the functional test logic may be:
1) Disabling offload runs ok, then the issue is likely igc/nic problem.
2) Disabling offload & issue comes back, this points to something else, maybe iflib.c
Quote from: tuto2 on July 01, 2026, 02:06:43 PMWhile having a look at this issue, I noticed a potential bug in the iflib code making an automatic reset in case of a TX hang impossible, a custom kernel has been published which resolves this (though likely not the final patch version). Would you mind installing this kernel to see if this changes anything about the issue?
Ok, reverted all tunables to defaults this morning and installed this kernel. Didn't have to wait long. The issue just popped up again. Again it was a down/up on the LAN interface (igc0) that resolved it. I do not see any references to watchdog timeouts, or indeed anything other that my work this morning and the reset I just did in dmesg or syslog. Here's the sysctl output on the interface while the issue was happening:
dev.igc.0.interrupts.rx_desc_min_thresh: 0
dev.igc.0.interrupts.asserts: 2544406
dev.igc.0.mac_stats.tso_txd: 0
dev.igc.0.mac_stats.tx_frames_1024_1522: 3606676
dev.igc.0.mac_stats.tx_frames_512_1023: 14052
dev.igc.0.mac_stats.tx_frames_256_511: 17180
dev.igc.0.mac_stats.tx_frames_128_255: 26586
dev.igc.0.mac_stats.tx_frames_65_127: 105743
dev.igc.0.mac_stats.tx_frames_64: 5542
dev.igc.0.mac_stats.mcast_pkts_txd: 2184
dev.igc.0.mac_stats.bcast_pkts_txd: 83
dev.igc.0.mac_stats.good_pkts_txd: 3775779
dev.igc.0.mac_stats.total_pkts_txd: 3775779
dev.igc.0.mac_stats.good_octets_txd: 5499410065
dev.igc.0.mac_stats.good_octets_recvd: 179427410
dev.igc.0.mac_stats.rx_frames_1024_1522: 28848
dev.igc.0.mac_stats.rx_frames_512_1023: 11786
dev.igc.0.mac_stats.rx_frames_256_511: 10339
dev.igc.0.mac_stats.rx_frames_128_255: 22011
dev.igc.0.mac_stats.rx_frames_65_127: 1596460
dev.igc.0.mac_stats.rx_frames_64: 26780
dev.igc.0.mac_stats.mcast_pkts_recvd: 3350
dev.igc.0.mac_stats.bcast_pkts_recvd: 44496
dev.igc.0.mac_stats.good_pkts_recvd: 1696224
dev.igc.0.mac_stats.total_pkts_recvd: 1705605
dev.igc.0.mac_stats.mgmt_pkts_txd: 0
dev.igc.0.mac_stats.mgmt_pkts_drop: 0
dev.igc.0.mac_stats.mgmt_pkts_recvd: 0
dev.igc.0.mac_stats.unsupported_fc_recvd: 0
dev.igc.0.mac_stats.xoff_txd: 0
dev.igc.0.mac_stats.xoff_recvd: 0
dev.igc.0.mac_stats.xon_txd: 0
dev.igc.0.mac_stats.xon_recvd: 0
dev.igc.0.mac_stats.alignment_errs: 0
dev.igc.0.mac_stats.crc_errs: 0
dev.igc.0.mac_stats.recv_errs: 0
dev.igc.0.mac_stats.recv_jabber: 0
dev.igc.0.mac_stats.recv_oversize: 0
dev.igc.0.mac_stats.recv_fragmented: 0
dev.igc.0.mac_stats.recv_undersize: 0
dev.igc.0.mac_stats.recv_no_buff: 0
dev.igc.0.mac_stats.recv_length_errors: 0
dev.igc.0.mac_stats.missed_packets: 197
dev.igc.0.mac_stats.defer_count: 0
dev.igc.0.mac_stats.sequence_errors: 0
dev.igc.0.mac_stats.symbol_errors: 0
dev.igc.0.mac_stats.collision_count: 0
dev.igc.0.mac_stats.late_coll: 0
dev.igc.0.mac_stats.multiple_coll: 0
dev.igc.0.mac_stats.single_coll: 0
dev.igc.0.mac_stats.excess_coll: 0
dev.igc.0.queue_rx_3.rx_irq: 0
dev.igc.0.queue_rx_3.rxd_tail: 612
dev.igc.0.queue_rx_3.rxd_head: 613
dev.igc.0.queue_rx_3.interrupt_rate: 20832
dev.igc.0.queue_rx_2.rx_irq: 0
dev.igc.0.queue_rx_2.rxd_tail: 368
dev.igc.0.queue_rx_2.rxd_head: 369
dev.igc.0.queue_rx_2.interrupt_rate: 20832
dev.igc.0.queue_rx_1.rx_irq: 0
dev.igc.0.queue_rx_1.rxd_tail: 830
dev.igc.0.queue_rx_1.rxd_head: 830
dev.igc.0.queue_rx_1.interrupt_rate: 4032
dev.igc.0.queue_rx_0.rx_irq: 0
dev.igc.0.queue_rx_0.rxd_tail: 605
dev.igc.0.queue_rx_0.rxd_head: 606
dev.igc.0.queue_rx_0.interrupt_rate: 20832
dev.igc.0.queue_tx_3.tx_irq: 0
dev.igc.0.queue_tx_3.txd_tail: 173
dev.igc.0.queue_tx_3.txd_head: 173
dev.igc.0.queue_tx_3.interrupt_rate: 20832
dev.igc.0.queue_tx_2.tx_irq: 0
dev.igc.0.queue_tx_2.txd_tail: 1000
dev.igc.0.queue_tx_2.txd_head: 1000
dev.igc.0.queue_tx_2.interrupt_rate: 20832
dev.igc.0.queue_tx_1.tx_irq: 0
dev.igc.0.queue_tx_1.txd_tail: 46
dev.igc.0.queue_tx_1.txd_head: 46
dev.igc.0.queue_tx_1.interrupt_rate: 4032
dev.igc.0.queue_tx_0.tx_irq: 0
dev.igc.0.queue_tx_0.txd_tail: 735
dev.igc.0.queue_tx_0.txd_head: 735
dev.igc.0.queue_tx_0.interrupt_rate: 20832
dev.igc.0.fc_low_water: 32752
dev.igc.0.fc_high_water: 32768
dev.igc.0.rx_control: 71335938
dev.igc.0.device_control: 1075578433
dev.igc.0.watchdog_timeouts: 0
dev.igc.0.rx_overruns: 0
dev.igc.0.link_irq: 3
dev.igc.0.dropped: 0
dev.igc.0.eee_control: 1
dev.igc.0.tso_tcp_flags_mask_last_segment: 3967
dev.igc.0.tso_tcp_flags_mask_middle_segment: 3958
dev.igc.0.tso_tcp_flags_mask_first_segment: 4086
dev.igc.0.dmac: 0
dev.igc.0.rs_dump: 0
dev.igc.0.reg_dump: General Registers
CTRL 401c0641
STATUS 00380683
CTRL_EXIT 100000c0
Interrupt Registers
ICR 00000000
RX Registers
RCTL 04408002
RDLEN 00004000
RDH 0000025e
RDT 0000025d
RXDCTL 02040808
RDBAL 75d88000
RDBAH 00000000
TX Registers
TCTL a503f0fa
TDBAL 750f8000
TDBAH 00000000
TDLEN 00004000
TDH 000002df
TDT 000002df
TXDCTL 0201011f
TDFH 00000000
TDFT 00000000
TDFHS 00000000
TDFPC 00000000
dev.igc.0.fc: 3
dev.igc.0.debug: -1
dev.igc.0.fw_version: EEPROM V2.17-0 eTrack 0x80000303
dev.igc.0.enable_aim: 1
dev.igc.0.nvm: -1
dev.igc.0.iflib.rxq3.rxq_fl0.buf_size: 2048
dev.igc.0.iflib.rxq3.rxq_fl0.credits: 1023
dev.igc.0.iflib.rxq3.rxq_fl0.cidx: 613
dev.igc.0.iflib.rxq3.rxq_fl0.pidx: 612
dev.igc.0.iflib.rxq3.cpu: 3
dev.igc.0.iflib.rxq2.rxq_fl0.buf_size: 2048
dev.igc.0.iflib.rxq2.rxq_fl0.credits: 1023
dev.igc.0.iflib.rxq2.rxq_fl0.cidx: 369
dev.igc.0.iflib.rxq2.rxq_fl0.pidx: 368
dev.igc.0.iflib.rxq2.cpu: 2
dev.igc.0.iflib.rxq1.rxq_fl0.buf_size: 2048
dev.igc.0.iflib.rxq1.rxq_fl0.credits: 1023
dev.igc.0.iflib.rxq1.rxq_fl0.cidx: 831
dev.igc.0.iflib.rxq1.rxq_fl0.pidx: 830
dev.igc.0.iflib.rxq1.cpu: 1
dev.igc.0.iflib.rxq0.rxq_fl0.buf_size: 2048
dev.igc.0.iflib.rxq0.rxq_fl0.credits: 1023
dev.igc.0.iflib.rxq0.rxq_fl0.cidx: 606
dev.igc.0.iflib.rxq0.rxq_fl0.pidx: 605
dev.igc.0.iflib.rxq0.cpu: 0
dev.igc.0.iflib.txq3.r_abdications: 0
dev.igc.0.iflib.txq3.r_restarts: 0
dev.igc.0.iflib.txq3.r_stalls: 0
dev.igc.0.iflib.txq3.r_starts: 256058
dev.igc.0.iflib.txq3.r_drops: 0
dev.igc.0.iflib.txq3.r_enqueues: 256060
dev.igc.0.iflib.txq3.ring_state: pidx_head: 0060 pidx_tail: 0060 cidx: 0060 state: IDLE
dev.igc.0.iflib.txq3.txq_cleaned: 512129
dev.igc.0.iflib.txq3.txq_processed: 512169
dev.igc.0.iflib.txq3.txq_in_use: 44
dev.igc.0.iflib.txq3.txq_cidx_processed: 169
dev.igc.0.iflib.txq3.txq_cidx: 129
dev.igc.0.iflib.txq3.txq_pidx: 173
dev.igc.0.iflib.txq3.no_tx_dma_setup: 0
dev.igc.0.iflib.txq3.txd_encap_efbig: 0
dev.igc.0.iflib.txq3.tx_map_failed: 0
dev.igc.0.iflib.txq3.no_desc_avail: 0
dev.igc.0.iflib.txq3.mbuf_defrag_failed: 0
dev.igc.0.iflib.txq3.m_pullups: 0
dev.igc.0.iflib.txq3.mbuf_defrag: 0
dev.igc.0.iflib.txq3.cpu: 3
dev.igc.0.iflib.txq2.r_abdications: 0
dev.igc.0.iflib.txq2.r_restarts: 0
dev.igc.0.iflib.txq2.r_stalls: 0
dev.igc.0.iflib.txq2.r_starts: 195065
dev.igc.0.iflib.txq2.r_drops: 0
dev.igc.0.iflib.txq2.r_enqueues: 195065
dev.igc.0.iflib.txq2.ring_state: pidx_head: 0505 pidx_tail: 0505 cidx: 0505 state: IDLE
dev.igc.0.iflib.txq2.txq_cleaned: 390078
dev.igc.0.iflib.txq2.txq_processed: 390118
dev.igc.0.iflib.txq2.txq_in_use: 42
dev.igc.0.iflib.txq2.txq_cidx_processed: 998
dev.igc.0.iflib.txq2.txq_cidx: 958
dev.igc.0.iflib.txq2.txq_pidx: 1000
dev.igc.0.iflib.txq2.no_tx_dma_setup: 0
dev.igc.0.iflib.txq2.txd_encap_efbig: 0
dev.igc.0.iflib.txq2.tx_map_failed: 0
dev.igc.0.iflib.txq2.no_desc_avail: 0
dev.igc.0.iflib.txq2.mbuf_defrag_failed: 0
dev.igc.0.iflib.txq2.m_pullups: 0
dev.igc.0.iflib.txq2.mbuf_defrag: 0
dev.igc.0.iflib.txq2.cpu: 2
dev.igc.0.iflib.txq1.r_abdications: 0
dev.igc.0.iflib.txq1.r_restarts: 0
dev.igc.0.iflib.txq1.r_stalls: 0
dev.igc.0.iflib.txq1.r_starts: 3023378
dev.igc.0.iflib.txq1.r_drops: 0
dev.igc.0.iflib.txq1.r_enqueues: 3023383
dev.igc.0.iflib.txq1.ring_state: pidx_head: 0535 pidx_tail: 0535 cidx: 0535 state: IDLE
dev.igc.0.iflib.txq1.txq_cleaned: 6046724
dev.igc.0.iflib.txq1.txq_processed: 6046764
dev.igc.0.iflib.txq1.txq_in_use: 42
dev.igc.0.iflib.txq1.txq_cidx_processed: 44
dev.igc.0.iflib.txq1.txq_cidx: 4
dev.igc.0.iflib.txq1.txq_pidx: 46
dev.igc.0.iflib.txq1.no_tx_dma_setup: 0
dev.igc.0.iflib.txq1.txd_encap_efbig: 0
dev.igc.0.iflib.txq1.tx_map_failed: 0
dev.igc.0.iflib.txq1.no_desc_avail: 0
dev.igc.0.iflib.txq1.mbuf_defrag_failed: 0
dev.igc.0.iflib.txq1.m_pullups: 0
dev.igc.0.iflib.txq1.mbuf_defrag: 0
dev.igc.0.iflib.txq1.cpu: 1
dev.igc.0.iflib.txq0.r_abdications: 0
dev.igc.0.iflib.txq0.r_restarts: 0
dev.igc.0.iflib.txq0.r_stalls: 0
dev.igc.0.iflib.txq0.r_starts: 301485
dev.igc.0.iflib.txq0.r_drops: 0
dev.igc.0.iflib.txq0.r_enqueues: 301488
dev.igc.0.iflib.txq0.ring_state: pidx_head: 0432 pidx_tail: 0432 cidx: 0432 state: IDLE
dev.igc.0.iflib.txq0.txq_cleaned: 602805
dev.igc.0.iflib.txq0.txq_processed: 602845
dev.igc.0.iflib.txq0.txq_in_use: 42
dev.igc.0.iflib.txq0.txq_cidx_processed: 733
dev.igc.0.iflib.txq0.txq_cidx: 693
dev.igc.0.iflib.txq0.txq_pidx: 735
dev.igc.0.iflib.txq0.no_tx_dma_setup: 0
dev.igc.0.iflib.txq0.txd_encap_efbig: 0
dev.igc.0.iflib.txq0.tx_map_failed: 0
dev.igc.0.iflib.txq0.no_desc_avail: 0
dev.igc.0.iflib.txq0.mbuf_defrag_failed: 0
dev.igc.0.iflib.txq0.m_pullups: 3
dev.igc.0.iflib.txq0.mbuf_defrag: 0
dev.igc.0.iflib.txq0.cpu: 0
dev.igc.0.iflib.override_nrxds: 0
dev.igc.0.iflib.override_ntxds: 0
dev.igc.0.iflib.allocated_msix_vectors: 5
dev.igc.0.iflib.use_extra_msix_vectors: 0
dev.igc.0.iflib.use_logical_cores: 0
dev.igc.0.iflib.separate_txrx: 0
dev.igc.0.iflib.core_offset: 0
dev.igc.0.iflib.tx_abdicate: 0
dev.igc.0.iflib.rx_budget: 0
dev.igc.0.iflib.disable_msix: 0
dev.igc.0.iflib.override_qs_enable: 0
dev.igc.0.iflib.override_nrxqs: 0
dev.igc.0.iflib.override_ntxqs: 0
dev.igc.0.iflib.driver_version: 1
dev.igc.0.%iommu: rid=0x100
dev.igc.0.%parent: pci1
dev.igc.0.%pnpinfo: vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000 class=0x020000
dev.igc.0.%location: slot=0 function=0 dbsf=pci0:1:0:0
dev.igc.0.%driver: igc
dev.igc.0.%desc: Intel(R) Ethernet Controller I226-V
Quote from: fornax on July 10, 2026, 06:03:16 AMOk, reverted all tunables to defaults this morning and installed this kernel. Didn't have to wait long. The issue just popped up again. Again it was a down/up on the LAN interface (igc0) that resolved it. I do not see any references to watchdog timeouts, or indeed anything other that my work this morning and the reset I just did in dmesg or syslog. Here's the sysctl output on the interface while the issue was happening:
Ok, getting closer..
Can you try:
# opnsense-update -zkr 26.1.11-igc_aspm
and reboot?
Ref: https://github.com/freebsd/freebsd-src/pull/2318
Hold up...
Quote from: fornax on July 10, 2026, 06:03:16 AMdev.igc.0.fw_version: EEPROM V2.17-0 eTrack 0x80000303
This is before any of the fixes Intel pushed for related stuff.. The baseline should be 2.25.
Uggg... I just received a brand new VP4650 with 6x i226 ports to replace my old recycled OPNsense server. I'm also on Business so fixes might be a while.
I guess I wait and maybe burn it in on my lab?
I'll be watching this. And before I bought this the sales person spoke to Protectli, and I spoke to Protectli about using this with OPNsense, the only thing they said was that I probably want to run Coreboot, but can switch back and forth at any time.
Considering the difficulty of people in the USA for getting Deciso based hardware, Protectli is about the best choice. And they were on government contract which helped me buy it for work. Seems like there might be a spot for more of a partnership between Protectli and Deciso/OPNsense.
[edit] I sent an email to the sales contact I made a few months ago, linked this thread. Maybe we can get Protecli on this to help out. The OPNsense hardware wasn't really an option for me here in the USA, which is why I ended up with a Protectli device.
You're troubleshooting while on old problematic NVM. Why
?Your 226's are five (5) revs behind. Start at step #1, update NVM.
Also a note for readers, in this thread the NVM is the 2MB version. 2MB versions have more features in it, makes me wonder if this issue is specific to the 2MB version?
v2.25
Bug Fix:
• HSD 13010560068: Link Flaps with Energy Efficient Ethernet Enabled
There's also a 2MB v2.27 and a v2.32 available.
Oddly from the billy curtis notes (fixes section), v2.22 states the link flap issue was fixed, but in v2.25 the same issue is fixed again.
Also to note, ASPM and EE are not the same. Best recommendation is to disable ASPM and then tune EE C states so that nothing can ever go 100% sleep.
EEE for igc can be done via sysctl
sysctl hw.igc.eee_setting=1
sysctl dev.igc.0.eee_control=1
sysctl dev.igc.1.eee_control=1
And I not sure why, I think this was mentioned by another user elsewhere, the logic is backwards in the actual c code. "1" means to disable
(which should be default), and "0" means enable. I mentioned 802.3az in the other thread some time ago.
EDIT: the bolded part about default, I am perhaps not correct, not sure. The notes on billy curtis github says v2.13 disabled EEE by default, but in v2.14 it says EEE is enabled by the driver. Not 100% clear to me if v2.14 means enabled by driver by default. Best to just hard set what you want and don't rely on defaults.
QuoteWhen EEE is enabled, the igc NIC uses the IEEE 802.3az "Energy Efficient Ethernet" behavior: during periods of low/no transmit activity it can reduce link power by entering Low Power Idle (LPI) (often coordinated with the switch/peer), then wake up quickly when traffic resumes. The goal is to cut power use during low utilization while keeping normal connectivity.
@Greg_E the kernel mentioned above is also on the business mirror to try.
Cheers,
Franco
Ok, thanks for the additional comments. As mentioned in the original post, I haven't updated the NVM because frankly it's a bit intimidating. As far as I can tell Protectli only provides an update for one model (that isn't mine), so I'm going third-party for something that can brick the interface. Sounds like that may be what I need to do anyway though. I'll try a plea to Protectli while I prepare.
There are two fixes offered in this thread, one in the FreeBSD kernel (in development) and one in the OPNsense custom kernel (-iflib variant, requiring newer NVM). Are they redundant or targeting different issues?
BTW, Protectli have a statement about why they can't distribute i226 NVM updates at the bottom of this document: https://kb.protectli.com/kb/how-to-update-intel-nic-nvm-firmware-on-protectli-vaults/. They link to the thread here with the BillyCurtis images, for those needing to do it.
Quote from: OPNenthu on July 10, 2026, 09:17:32 PMBTW, Protectli have a statement about why they can't distribute i226 NVM updates at the bottom of this document: https://kb.protectli.com/kb/how-to-update-intel-nic-nvm-firmware-on-protectli-vaults/. They link to the thread here with the BillyCurtis images, for those needing to do it.
Thanks, I missed that bit. Sounds like I just need to hold my breath and do it. They specifically mention they've validated an update to 2.27.
Is there any compelling reason to consider 2.32? (Edit: Scratch that, I got a response from Protectli pointing at 2.32, so I'll go ahead and try that. They also mentioned I may have better luck with AMI BIOS vs. coreboot. I need to get some clarification, but will proceed with one or both and report back.)
Quote from: fornax on July 10, 2026, 09:55:43 PM(Edit: Scratch that, I got a response from Protectli pointing at 2.32, so I'll go ahead and try that. They also mentioned I may have better luck with AMI BIOS vs. coreboot. I need to get some clarification, but will proceed with one or both and report back.)
Thanks for confirming 2.32 is vendor approved.
I am still on v2.13 myself:
root@firewall:~ # sysctl dev.igc.0.fw_version
dev.igc.0.fw_version: EEPROM V2.13-0 eTrack 0x8000028
I don't have link flaps or anything like that and my NICs are otherwise stable and with clean statistics (no errors & low/no drops) so I was holding off.
As a second data point/test in addition to yours, I went ahead and applied the 'igc_aspm' kernel:
root@firewall:~ # uname -a
FreeBSD firewall.h1.home.arpa 14.3-RELEASE-p16 FreeBSD 14.3-RELEASE-p16 igc_aspm-n272154-6f771ce68454 SMP amd64
... but, I left the NVM firmware as-is. Reason being, the upstream Linux patch this is sourced from does not stipulate any particular NVM version as being required.
Let's compare notes after some time. I'm staying on coreboot. The Intel ME disable (HAP disable) is too good to let go :)
Just a note for readers, a warning.
The billy curtis NVM images are just that, they have not been officially validated as authentic Intel images.
In the other thread for i226 NVM I had only validated that one of the i226 VVM versions I obtained from another hardware vendors matched the same one on billy curtis github (SHA256 matching). The other hardware vendor is known-legit and said the NVM was from Intel. Beyond that the other NVM images I cannot validate in any way because finding them anywhere else is very difficult.
So, if your FW system is critical in any way, then I recommend you call Intel and demand a copy of NVM directly from them.
For non-critical, we can use the billy curtis downloads. Always a risk using non-official stuff, etc.
What I might expect from Protectli support is, they obtain and publish just the SHA256 hashes of the official Intel NVM's for freeBSD so that we can compare to the downloads we get from non-official sources. This way we have something pseudo-trusted, and Protectli stays compliant for not hosting the NVM images.
It's still a bit baffling as to why Intel simply doesnt host the NVM images for their products. Buy MU shares instead of INTC. ;)
Quote from: OPNenthu on July 11, 2026, 12:26:50 AMI am still on v2.13 myself:
... but, I left the NVM firmware as-is. Reason being, the upstream Linux patch this is sourced from does not stipulate any particular NVM version as being required.
Yikes.
We covered this a lot in many threads.
Drivers and NVM's are basically linked. Newer drivers typically are updated to use new features in newer firmware. Driver code is also sometimes fixed for the bugs they carry.
If Intel is updating NVM then we know it's not because they needed something to keep them busy, they did updating for a reason. And there's no functional reason not to run the latest NVM code. Same goes for their driver code. For long running hardware (i225 i226 as example), newer drivers (KLM's) are almost 100% better to run than older drivers. Unfortunately for most the GENERIC kernel builds compile in that code making it very difficult to just unload the old and load in the new, which was the whole point of KLM feature. I showed how to recompile kernel w/o the igc in it, then I just loaded in whatever igc driver that I wanted as KLM.
So, full circle on this issue.
Quote from: BrandyWine on July 11, 2026, 12:32:37 AMWhat I might expect from Protectli support is, they obtain and publish just the SHA256 hashes of the official Intel NVM's for freeBSD
Sounds like a good compromise. Hope they can do it.
Quote from: BrandyWine on July 11, 2026, 12:32:37 AMt's still a bit baffling as to why Intel simply doesnt host the NVM images for their products. Buy MU shares instead of INTC. ;)
I can understand why they differentiate this way between server and consumer/embedded parts, but yeah this situation is frustrating. Micron also turned its back on the consumer market and now we're finding out that memory makers may have colluded to fix prices. All of them need to face a reckoning, IMO.
Quote from: OPNenthu on July 11, 2026, 12:26:50 AMThanks for confirming 2.32 is vendor approved.
"Vendor approved" is probably overstating it. I'll just say that the Protectli support rep working with me indicated that he tested the upgrade to that version and used it in his guidance to me for the procedure.
At any rate, I successfully updated:
[1] igc0: <Intel(R) Ethernet Controller I226-V> mem 0x80400000-0x804fffff,0x80600000-0x80603fff at device 0.0 on pci1
[1] igc0: EEPROM V2.32-0 eTrack 0x80000422
[1] igc0: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc0: Using 4 RX queues 4 TX queues
[1] igc0: Using MSI-X interrupts with 5 vectors
[1] igc0: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igc1: <Intel(R) Ethernet Controller I226-V> mem 0x80700000-0x807fffff,0x80900000-0x80903fff at device 0.0 on pci2
[1] igc1: EEPROM V2.32-0 eTrack 0x80000422
[1] igc1: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc1: Using 4 RX queues 4 TX queues
[1] igc1: Using MSI-X interrupts with 5 vectors
[1] igc1: netmap queues/slots: TX 4/1024, RX 4/1024I haven't changed anything else yet. Still on the -iflib kernel, no tunables, still on coreboot. I'm going to monitor for a bit, and if/when it pops up again I'll go from there.
I'd like to reiterate that this is a real world easy to test approach that requires *actual feedback*:
Quote from: tuto2 on July 10, 2026, 02:56:07 PMQuote from: fornax on July 10, 2026, 06:03:16 AMOk, reverted all tunables to defaults this morning and installed this kernel. Didn't have to wait long. The issue just popped up again. Again it was a down/up on the LAN interface (igc0) that resolved it. I do not see any references to watchdog timeouts, or indeed anything other that my work this morning and the reset I just did in dmesg or syslog. Here's the sysctl output on the interface while the issue was happening:
Ok, getting closer..
Can you try:
# opnsense-update -zkr 26.1.11-igc_aspm
and reboot?
Ref: https://github.com/freebsd/freebsd-src/pull/2318
Ok, the issue popped up again this morning, verifying that the NVM update didn't in itself fix anything. I just installed the igc_aspm kernel, so we'll see how that goes now.
root@scutum:~ # uname -a
FreeBSD scutum.nightsky.internal 14.3-RELEASE-p16 FreeBSD 14.3-RELEASE-p16 igc_aspm-n272154-6f771ce68454 SMP amd64
Quote from: fornax on July 13, 2026, 12:20:02 AMOk, the issue popped up again this morning, verifying that the NVM update didn't in itself fix anything. I just installed the igc_aspm kernel, so we'll see how that goes now.
root@scutum:~ # uname -a
FreeBSD scutum.nightsky.internal 14.3-RELEASE-p16 FreeBSD 14.3-RELEASE-p16 igc_aspm-n272154-6f771ce68454 SMP amd64
In post #30 you mention you installed a kernel, which kernel was that one? Between #30 and #31 you installed two kernels ??
Quote from: BrandyWine on July 13, 2026, 03:24:42 AMIn post #30 you mention you installed a kernel, which kernel was that one? Between #30 and #31 you installed two kernels ??
From post #16 until this morning I was on the -iflib kernel mentioned in post #2 (post #30 quoted post #16). Prior to that I was on the stock kernel.
As @Franco recommended, you should absolutely try "opnsense-update -zkr 26.1.11-igc_aspm", because that should fix the hangup condition.
BTW: This is the original bug report (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279245).
Quote from: meyergru on July 13, 2026, 09:39:18 AMAs @Franco recommended, you should absolutely try "opnsense-update -zkr 26.1.11-igc_aspm", because that should fix the hangup condition.
Yep, as mentioned, that's what I'm on now.
https://github.com/freebsd/freebsd-src/pull/2318
Is this patch included in OPNsense v26.7?
Quote from: Lucid1010 on July 13, 2026, 02:19:49 PMhttps://github.com/freebsd/freebsd-src/pull/2318
Is this patch included in OPNsense v26.7?
It will be, though feedback is the important bit here.
I got a response from Protectli:
#1 my VP4650 shouldn't have this problem.
#2 they offered another document regarding ASPM for the older devices:
https://kb.protectli.com/wp-content/uploads/sites/9/2026/02/TSB-2025-001_VP2440-ASPM-Network-Interface-Performance-Issue-v2_0.pdf
Hopefully they watch this thread to see the outcome and distill it back into another KB document.
Quote from: Greg_E on July 13, 2026, 04:53:16 PM#2 they offered another document regarding ASPM for the older devices:
https://kb.protectli.com/wp-content/uploads/sites/9/2026/02/TSB-2025-001_VP2440-ASPM-Network-Interface-Performance-Issue-v2_0.pdf
Sounds like their coreboot fix is doing the same/similar thing as the kernel patch? If so, I wonder why they didn't extend that to their other models with i226-Vs.
Update:
I had installed the 'igc_aspm' kernel on a system with all i226-V NICs having NVM firmware 2.13 (an old version). The patch appears safe on this older firmware and hasn't caused any problems that I've seen so far. The earlier advice to start from at least a 2.25 baseline is probably sound, but at least there's no observed impact here.
I was not having link flaps or speed degradation in any case. I was hoping to clear up the frequent dpinger drops that I see which cause a lot of unecessary failovers for gatways groups (such as VPNs), but unfortunately the patch didn't help that. I'm guessing my issue is not localized and could just be the ISP infrastructure or upstream routers.
Might work up the courage to upgrade the NVM but I really don't have any of the typical problem indications that are worth the risk AFAICT.
WAN link data for reference...
root@firewall:~ # netstat -I igc1
Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll
igc1 1500 <Link#2> xx:xx:xx:xx:xx:xx 100279348 0 0 38220783 0 0
igc1 - fe80::%igc1/64 fe80::xx:xxxx:xxxx:xxxx%igc1 2242 - - 2728 - -
igc1 - 69.xxx.xxx.xxx/22 xxx.xxx.xx.comcast.net 42381670 - - 13944744 - -
igc1 - 10.0.0.0/30 10.0.0.2 0 - - 0 - -
igc1 - xxxx:xx:xxxx:1b77::/64 xxxx:xx:xxxx:1b77:xxxx:xxxx:xxxx:xxxx 331055 - - 394721 - -
root@firewall:~ # sysctl dev.igc.1
dev.igc.1.interrupts.rx_desc_min_thresh: 0
dev.igc.1.interrupts.asserts: 107822263
dev.igc.1.mac_stats.tso_txd: 0
dev.igc.1.mac_stats.tx_frames_1024_1522: 599302
dev.igc.1.mac_stats.tx_frames_512_1023: 460622
dev.igc.1.mac_stats.tx_frames_256_511: 210904
dev.igc.1.mac_stats.tx_frames_128_255: 13631408
dev.igc.1.mac_stats.tx_frames_65_127: 23107378
dev.igc.1.mac_stats.tx_frames_64: 213312
dev.igc.1.mac_stats.mcast_pkts_txd: 46
dev.igc.1.mac_stats.bcast_pkts_txd: 181
dev.igc.1.mac_stats.good_pkts_txd: 38222926
dev.igc.1.mac_stats.total_pkts_txd: 38222926
dev.igc.1.mac_stats.good_octets_txd: 4995909586
dev.igc.1.mac_stats.good_octets_recvd: 138811724686
dev.igc.1.mac_stats.rx_frames_1024_1522: 96022714
dev.igc.1.mac_stats.rx_frames_512_1023: 472886
dev.igc.1.mac_stats.rx_frames_256_511: 483889
dev.igc.1.mac_stats.rx_frames_128_255: 1734860
dev.igc.1.mac_stats.rx_frames_65_127: 1327632
dev.igc.1.mac_stats.rx_frames_64: 239883
dev.igc.1.mac_stats.mcast_pkts_recvd: 98216
dev.igc.1.mac_stats.bcast_pkts_recvd: 137
dev.igc.1.mac_stats.good_pkts_recvd: 100281864
dev.igc.1.mac_stats.total_pkts_recvd: 100283378
dev.igc.1.mac_stats.mgmt_pkts_txd: 0
dev.igc.1.mac_stats.mgmt_pkts_drop: 0
dev.igc.1.mac_stats.mgmt_pkts_recvd: 0
dev.igc.1.mac_stats.unsupported_fc_recvd: 0
dev.igc.1.mac_stats.xoff_txd: 0
dev.igc.1.mac_stats.xoff_recvd: 0
dev.igc.1.mac_stats.xon_txd: 0
dev.igc.1.mac_stats.xon_recvd: 0
dev.igc.1.mac_stats.alignment_errs: 0
dev.igc.1.mac_stats.crc_errs: 0
dev.igc.1.mac_stats.recv_errs: 0
dev.igc.1.mac_stats.recv_jabber: 0
dev.igc.1.mac_stats.recv_oversize: 0
dev.igc.1.mac_stats.recv_fragmented: 0
dev.igc.1.mac_stats.recv_undersize: 0
dev.igc.1.mac_stats.recv_no_buff: 0
dev.igc.1.mac_stats.recv_length_errors: 0
dev.igc.1.mac_stats.missed_packets: 0
dev.igc.1.mac_stats.defer_count: 0
dev.igc.1.mac_stats.sequence_errors: 0
dev.igc.1.mac_stats.symbol_errors: 0
dev.igc.1.mac_stats.collision_count: 0
dev.igc.1.mac_stats.late_coll: 0
dev.igc.1.mac_stats.multiple_coll: 0
dev.igc.1.mac_stats.single_coll: 0
dev.igc.1.mac_stats.excess_coll: 0
dev.igc.1.queue_rx_3.rx_irq: 0
dev.igc.1.queue_rx_3.rxd_tail: 733
dev.igc.1.queue_rx_3.rxd_head: 734
dev.igc.1.queue_rx_3.interrupt_rate: 20832
dev.igc.1.queue_rx_2.rx_irq: 0
dev.igc.1.queue_rx_2.rxd_tail: 621
dev.igc.1.queue_rx_2.rxd_head: 622
dev.igc.1.queue_rx_2.interrupt_rate: 20832
dev.igc.1.queue_rx_1.rx_irq: 0
dev.igc.1.queue_rx_1.rxd_tail: 145
dev.igc.1.queue_rx_1.rxd_head: 146
dev.igc.1.queue_rx_1.interrupt_rate: 20832
dev.igc.1.queue_rx_0.rx_irq: 0
dev.igc.1.queue_rx_0.rxd_tail: 808
dev.igc.1.queue_rx_0.rxd_head: 809
dev.igc.1.queue_rx_0.interrupt_rate: 20832
dev.igc.1.queue_tx_3.tx_irq: 0
dev.igc.1.queue_tx_3.txd_tail: 329
dev.igc.1.queue_tx_3.txd_head: 329
dev.igc.1.queue_tx_3.interrupt_rate: 20832
dev.igc.1.queue_tx_2.tx_irq: 0
dev.igc.1.queue_tx_2.txd_tail: 471
dev.igc.1.queue_tx_2.txd_head: 471
dev.igc.1.queue_tx_2.interrupt_rate: 20832
dev.igc.1.queue_tx_1.tx_irq: 0
dev.igc.1.queue_tx_1.txd_tail: 980
dev.igc.1.queue_tx_1.txd_head: 980
dev.igc.1.queue_tx_1.interrupt_rate: 20832
dev.igc.1.queue_tx_0.tx_irq: 0
dev.igc.1.queue_tx_0.txd_tail: 240
dev.igc.1.queue_tx_0.txd_head: 240
dev.igc.1.queue_tx_0.interrupt_rate: 20832
dev.igc.1.fc_low_water: 32752
dev.igc.1.fc_high_water: 32768
dev.igc.1.rx_control: 71335938
dev.igc.1.device_control: 404489793
dev.igc.1.watchdog_timeouts: 0
dev.igc.1.rx_overruns: 0
dev.igc.1.link_irq: 18
dev.igc.1.dropped: 0
dev.igc.1.eee_control: 1
dev.igc.1.tso_tcp_flags_mask_last_segment: 3967
dev.igc.1.tso_tcp_flags_mask_middle_segment: 3958
dev.igc.1.tso_tcp_flags_mask_first_segment: 4086
dev.igc.1.dmac: 0
dev.igc.1.rs_dump: 0
dev.igc.1.reg_dump: General Registers
CTRL 181c0641
STATUS 00780683
CTRL_EXIT 100000c0
Interrupt Registers
ICR 00000000
RX Registers
RCTL 04408002
RDLEN 00004000
RDH 00000329
RDT 00000328
RXDCTL 02040808
RDBAL 76e4c000
RDBAH 00000000
TX Registers
TCTL a503f0fa
TDBAL 76dbc000
TDBAH 00000000
TDLEN 00004000
TDH 000000f0
TDT 000000f0
TXDCTL 0201011f
TDFH 00000000
TDFT 00000000
TDFHS 00000000
TDFPC 00000000
dev.igc.1.fc: 3
dev.igc.1.debug: -1
dev.igc.1.fw_version: EEPROM V2.13-0 eTrack 0x80000286
dev.igc.1.enable_aim: 1
dev.igc.1.nvm: -1
dev.igc.1.iflib.rxq3.rxq_fl0.buf_size: 2048
dev.igc.1.iflib.rxq3.rxq_fl0.credits: 1023
dev.igc.1.iflib.rxq3.rxq_fl0.cidx: 734
dev.igc.1.iflib.rxq3.rxq_fl0.pidx: 733
dev.igc.1.iflib.rxq3.cpu: 3
dev.igc.1.iflib.rxq2.rxq_fl0.buf_size: 2048
dev.igc.1.iflib.rxq2.rxq_fl0.credits: 1023
dev.igc.1.iflib.rxq2.rxq_fl0.cidx: 622
dev.igc.1.iflib.rxq2.rxq_fl0.pidx: 621
dev.igc.1.iflib.rxq2.cpu: 2
dev.igc.1.iflib.rxq1.rxq_fl0.buf_size: 2048
dev.igc.1.iflib.rxq1.rxq_fl0.credits: 1023
dev.igc.1.iflib.rxq1.rxq_fl0.cidx: 146
dev.igc.1.iflib.rxq1.rxq_fl0.pidx: 145
dev.igc.1.iflib.rxq1.cpu: 1
dev.igc.1.iflib.rxq0.rxq_fl0.buf_size: 2048
dev.igc.1.iflib.rxq0.rxq_fl0.credits: 1023
dev.igc.1.iflib.rxq0.rxq_fl0.cidx: 809
dev.igc.1.iflib.rxq0.rxq_fl0.pidx: 808
dev.igc.1.iflib.rxq0.cpu: 0
dev.igc.1.iflib.txq3.r_abdications: 0
dev.igc.1.iflib.txq3.r_restarts: 0
dev.igc.1.iflib.txq3.r_stalls: 0
dev.igc.1.iflib.txq3.r_starts: 7796885
dev.igc.1.iflib.txq3.r_drops: 0
dev.igc.1.iflib.txq3.r_enqueues: 7797973
dev.igc.1.iflib.txq3.ring_state: pidx_head: 1237 pidx_tail: 1237 cidx: 1237 state: IDLE
dev.igc.1.iflib.txq3.txq_cleaned: 7985439
dev.igc.1.iflib.txq3.txq_processed: 7985479
dev.igc.1.iflib.txq3.txq_in_use: 42
dev.igc.1.iflib.txq3.txq_cidx_processed: 327
dev.igc.1.iflib.txq3.txq_cidx: 287
dev.igc.1.iflib.txq3.txq_pidx: 329
dev.igc.1.iflib.txq3.no_tx_dma_setup: 0
dev.igc.1.iflib.txq3.txd_encap_efbig: 0
dev.igc.1.iflib.txq3.tx_map_failed: 0
dev.igc.1.iflib.txq3.no_desc_avail: 0
dev.igc.1.iflib.txq3.mbuf_defrag_failed: 0
dev.igc.1.iflib.txq3.m_pullups: 0
dev.igc.1.iflib.txq3.mbuf_defrag: 0
dev.igc.1.iflib.txq3.cpu: 3
dev.igc.1.iflib.txq2.r_abdications: 0
dev.igc.1.iflib.txq2.r_restarts: 0
dev.igc.1.iflib.txq2.r_stalls: 0
dev.igc.1.iflib.txq2.r_starts: 5389171
dev.igc.1.iflib.txq2.r_drops: 0
dev.igc.1.iflib.txq2.r_enqueues: 5389985
dev.igc.1.iflib.txq2.ring_state: pidx_head: 1697 pidx_tail: 1697 cidx: 1697 state: IDLE
dev.igc.1.iflib.txq2.txq_cleaned: 5407150
dev.igc.1.iflib.txq2.txq_processed: 5407190
dev.igc.1.iflib.txq2.txq_in_use: 41
dev.igc.1.iflib.txq2.txq_cidx_processed: 470
dev.igc.1.iflib.txq2.txq_cidx: 430
dev.igc.1.iflib.txq2.txq_pidx: 471
dev.igc.1.iflib.txq2.no_tx_dma_setup: 0
dev.igc.1.iflib.txq2.txd_encap_efbig: 0
dev.igc.1.iflib.txq2.tx_map_failed: 0
dev.igc.1.iflib.txq2.no_desc_avail: 0
dev.igc.1.iflib.txq2.mbuf_defrag_failed: 0
dev.igc.1.iflib.txq2.m_pullups: 0
dev.igc.1.iflib.txq2.mbuf_defrag: 0
dev.igc.1.iflib.txq2.cpu: 2
dev.igc.1.iflib.txq1.r_abdications: 0
dev.igc.1.iflib.txq1.r_restarts: 0
dev.igc.1.iflib.txq1.r_stalls: 0
dev.igc.1.iflib.txq1.r_starts: 18676639
dev.igc.1.iflib.txq1.r_drops: 0
dev.igc.1.iflib.txq1.r_enqueues: 18677616
dev.igc.1.iflib.txq1.ring_state: pidx_head: 1904 pidx_tail: 1904 cidx: 1904 state: IDLE
dev.igc.1.iflib.txq1.txq_cleaned: 33628074
dev.igc.1.iflib.txq1.txq_processed: 33628114
dev.igc.1.iflib.txq1.txq_in_use: 42
dev.igc.1.iflib.txq1.txq_cidx_processed: 978
dev.igc.1.iflib.txq1.txq_cidx: 938
dev.igc.1.iflib.txq1.txq_pidx: 980
dev.igc.1.iflib.txq1.no_tx_dma_setup: 0
dev.igc.1.iflib.txq1.txd_encap_efbig: 0
dev.igc.1.iflib.txq1.tx_map_failed: 0
dev.igc.1.iflib.txq1.no_desc_avail: 0
dev.igc.1.iflib.txq1.mbuf_defrag_failed: 0
dev.igc.1.iflib.txq1.m_pullups: 0
dev.igc.1.iflib.txq1.mbuf_defrag: 0
dev.igc.1.iflib.txq1.cpu: 1
dev.igc.1.iflib.txq0.r_abdications: 0
dev.igc.1.iflib.txq0.r_restarts: 0
dev.igc.1.iflib.txq0.r_stalls: 0
dev.igc.1.iflib.txq0.r_starts: 6354534
dev.igc.1.iflib.txq0.r_drops: 0
dev.igc.1.iflib.txq0.r_enqueues: 6358392
dev.igc.1.iflib.txq0.ring_state: pidx_head: 1400 pidx_tail: 1400 cidx: 1400 state: IDLE
dev.igc.1.iflib.txq0.txq_cleaned: 6376647
dev.igc.1.iflib.txq0.txq_processed: 6376687
dev.igc.1.iflib.txq0.txq_in_use: 41
dev.igc.1.iflib.txq0.txq_cidx_processed: 239
dev.igc.1.iflib.txq0.txq_cidx: 199
dev.igc.1.iflib.txq0.txq_pidx: 240
dev.igc.1.iflib.txq0.no_tx_dma_setup: 0
dev.igc.1.iflib.txq0.txd_encap_efbig: 0
dev.igc.1.iflib.txq0.tx_map_failed: 0
dev.igc.1.iflib.txq0.no_desc_avail: 0
dev.igc.1.iflib.txq0.mbuf_defrag_failed: 0
dev.igc.1.iflib.txq0.m_pullups: 0
dev.igc.1.iflib.txq0.mbuf_defrag: 0
dev.igc.1.iflib.txq0.cpu: 0
dev.igc.1.iflib.override_nrxds: 0
dev.igc.1.iflib.override_ntxds: 0
dev.igc.1.iflib.allocated_msix_vectors: 5
dev.igc.1.iflib.use_extra_msix_vectors: 0
dev.igc.1.iflib.use_logical_cores: 0
dev.igc.1.iflib.separate_txrx: 0
dev.igc.1.iflib.core_offset: 0
dev.igc.1.iflib.tx_abdicate: 0
dev.igc.1.iflib.rx_budget: 0
dev.igc.1.iflib.disable_msix: 0
dev.igc.1.iflib.override_qs_enable: 0
dev.igc.1.iflib.override_nrxqs: 0
dev.igc.1.iflib.override_ntxqs: 0
dev.igc.1.iflib.driver_version: 1
dev.igc.1.%iommu: rid=0x200
dev.igc.1.%parent: pci2
dev.igc.1.%pnpinfo: vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000 class=0x020000
dev.igc.1.%location: slot=0 function=0 dbsf=pci0:2:0:0
dev.igc.1.%driver: igc
dev.igc.1.%desc: Intel(R) Ethernet Controller I226-V
I don't think it was ever asked. How exactly does your i226 ifaces (that are in use) ever go idle enough for either ASPM or EEE to turn them off? It's make no sense that any working iface would ever go idle enough to get into a deep power-down state.
It's still not clear if the issue resides in the 2MB or the 1MB NVM, nobody knows.
Unless someone can drum up a way to monitor ring/Tx/Rx/buffers/etc and power states of the NIC in realtime, the issue is cat-chasing-tail. I don't think it's a APSM or EEE problem at this point. I might suspect some 226's have a silicon gremlin.
@BrandyWine - not sure if you are responding to me or the OP but to answer your question, I really don't know.
Reading the FreeBSD bug that @meyergru posted, it seems like the stat counters don't indicate any issues so I can't truly rule anything out. Do I notice random disconnects? Well I don't really know how to measure for it, but just subjectively, yes. I think so. DNS resolutions sometimes time out as the OP states. Sites (even this one) sometimes don't load on the first try. Video streams sometimes drop & reconnect mid-stream.
Are these abnormal? Is a minimum baseline NVM version required for the ASPM fix to work?
When I had the problem on my Minisforum MS-01, it did not resolve by a NIC firmware upgrade. Not even disabling global ASPM helped (it did on some china boxes I have).
The problem went away after a BIOS update from Minisforum. So I figure that there are conditions where micro-sleeps trigger a hangup. ASPM potentially allows for those sleep states. It might be the case that Intel also tried to fix it in NIC firmware, however, there are several chip revisions out for I226V and some may have a hardware idiosyncrasy that causes this which cannot be healed via NIC firmware.
Intel seems to have "fixed" the hang problem by detecting it in the Linux driver and issuing a reset - FreeBSD has only now picked up that change in the OS driver (that was what my bug report was about).
So:
1. There are chip revisions (e.g., the latest ones have a smaller structure width and consume less power). You can see that via " pciconf -lv | grep -B3 igc", look at the "rev" value (mine is 0x04 on my current china box, I have others with 0x03). I think that early versions had a hardware problem that cause hangups. I did not investigate up to what revision these problems exist. I also do not remember which revision was on my Minisforum MS-01.
2. On some boxes, disabling ASPM globally via BIOS settings or tuneable does fix the problem, so you should try this.
3. On some boxes, you can get BIOS upgrades (e.g. Protectli, Minisforum).
4. My experience is that if the problems persist, updating the NIC firmare does not help.
5. In the future, we will have a FreeBSD driver with Intel's workaround that handles the remaining problems, the fixed kernel can be tested right now.
Quote from: meyergru on July 14, 2026, 09:43:14 AMIntel seems to have "fixed" the hang problem by detecting it in the Linux driver and issuing a reset - FreeBSD has only now picked up that change in the OS driver (that was what my bug report was about).
"TX hangs" have been around forever, which is why watchdog timeouts have been baked into iflib from the get-go (but broke somewhere along the way 5 years ago, the logic wasn't missing), the same goes for the Linux driver - the reset logic has been in there since the first commit. Nothing special about it. However, it being broken definitely hinted at other platforms only reporting "micro freezes" instead of full freezes.
I only assumed that the reset code was added later to Linux because it was missing in the FreeBSD driver, which otherwise looked like a port. I really did not do any software archeology. :-)
If that problem is handled in iflib in FreeBSD, it is not really needed in the hardware-specific driver.
If Intel knew that problem existed from the get-go, which would be implied if the hangup fix was there from the first commit, they should have better fixed it in hardware, though.
Unfortunately the -igc_aspm kernel didn't resolve my issue. It happened again this morning, and as usual bouncing the LAN interface with ifconfig down/up resolved it. There's nothing interesting in dmesg and the only recent entries in the syslog relate to a DHCP renewal for the WAN interface (which is not something I've seen in other instances).
I grabbed sysctl output again for the LAN interface before bouncing it in case it helps.
dev.igc.0.interrupts.rx_desc_min_thresh: 0
dev.igc.0.interrupts.asserts: 8611639
dev.igc.0.mac_stats.tso_txd: 0
dev.igc.0.mac_stats.tx_frames_1024_1522: 12886826
dev.igc.0.mac_stats.tx_frames_512_1023: 151170
dev.igc.0.mac_stats.tx_frames_256_511: 154980
dev.igc.0.mac_stats.tx_frames_128_255: 201503
dev.igc.0.mac_stats.tx_frames_65_127: 709277
dev.igc.0.mac_stats.tx_frames_64: 57830
dev.igc.0.mac_stats.mcast_pkts_txd: 12348
dev.igc.0.mac_stats.bcast_pkts_txd: 12306
dev.igc.0.mac_stats.good_pkts_txd: 14161586
dev.igc.0.mac_stats.total_pkts_txd: 14161586
dev.igc.0.mac_stats.good_octets_txd: 19562257880
dev.igc.0.mac_stats.good_octets_recvd: 1028354928
dev.igc.0.mac_stats.rx_frames_1024_1522: 242393
dev.igc.0.mac_stats.rx_frames_512_1023: 93689
dev.igc.0.mac_stats.rx_frames_256_511: 82963
dev.igc.0.mac_stats.rx_frames_128_255: 168419
dev.igc.0.mac_stats.rx_frames_65_127: 6872271
dev.igc.0.mac_stats.rx_frames_64: 298563
dev.igc.0.mac_stats.mcast_pkts_recvd: 14180
dev.igc.0.mac_stats.bcast_pkts_recvd: 294296
dev.igc.0.mac_stats.good_pkts_recvd: 7758298
dev.igc.0.mac_stats.total_pkts_recvd: 7812596
dev.igc.0.mac_stats.mgmt_pkts_txd: 0
dev.igc.0.mac_stats.mgmt_pkts_drop: 0
dev.igc.0.mac_stats.mgmt_pkts_recvd: 0
dev.igc.0.mac_stats.unsupported_fc_recvd: 0
dev.igc.0.mac_stats.xoff_txd: 0
dev.igc.0.mac_stats.xoff_recvd: 0
dev.igc.0.mac_stats.xon_txd: 0
dev.igc.0.mac_stats.xon_recvd: 0
dev.igc.0.mac_stats.alignment_errs: 0
dev.igc.0.mac_stats.crc_errs: 0
dev.igc.0.mac_stats.recv_errs: 0
dev.igc.0.mac_stats.recv_jabber: 0
dev.igc.0.mac_stats.recv_oversize: 0
dev.igc.0.mac_stats.recv_fragmented: 0
dev.igc.0.mac_stats.recv_undersize: 0
dev.igc.0.mac_stats.recv_no_buff: 0
dev.igc.0.mac_stats.recv_length_errors: 0
dev.igc.0.mac_stats.missed_packets: 0
dev.igc.0.mac_stats.defer_count: 0
dev.igc.0.mac_stats.sequence_errors: 0
dev.igc.0.mac_stats.symbol_errors: 0
dev.igc.0.mac_stats.collision_count: 0
dev.igc.0.mac_stats.late_coll: 0
dev.igc.0.mac_stats.multiple_coll: 0
dev.igc.0.mac_stats.single_coll: 0
dev.igc.0.mac_stats.excess_coll: 0
dev.igc.0.queue_rx_3.rx_irq: 0
dev.igc.0.queue_rx_3.rxd_tail: 475
dev.igc.0.queue_rx_3.rxd_head: 475
dev.igc.0.queue_rx_3.interrupt_rate: 4032
dev.igc.0.queue_rx_2.rx_irq: 0
dev.igc.0.queue_rx_2.rxd_tail: 153
dev.igc.0.queue_rx_2.rxd_head: 154
dev.igc.0.queue_rx_2.interrupt_rate: 20832
dev.igc.0.queue_rx_1.rx_irq: 0
dev.igc.0.queue_rx_1.rxd_tail: 482
dev.igc.0.queue_rx_1.rxd_head: 483
dev.igc.0.queue_rx_1.interrupt_rate: 20832
dev.igc.0.queue_rx_0.rx_irq: 0
dev.igc.0.queue_rx_0.rxd_tail: 511
dev.igc.0.queue_rx_0.rxd_head: 512
dev.igc.0.queue_rx_0.interrupt_rate: 20832
dev.igc.0.queue_tx_3.tx_irq: 0
dev.igc.0.queue_tx_3.txd_tail: 81
dev.igc.0.queue_tx_3.txd_head: 81
dev.igc.0.queue_tx_3.interrupt_rate: 4032
dev.igc.0.queue_tx_2.tx_irq: 0
dev.igc.0.queue_tx_2.txd_tail: 1018
dev.igc.0.queue_tx_2.txd_head: 1018
dev.igc.0.queue_tx_2.interrupt_rate: 20832
dev.igc.0.queue_tx_1.tx_irq: 0
dev.igc.0.queue_tx_1.txd_tail: 67
dev.igc.0.queue_tx_1.txd_head: 67
dev.igc.0.queue_tx_1.interrupt_rate: 20832
dev.igc.0.queue_tx_0.tx_irq: 0
dev.igc.0.queue_tx_0.txd_tail: 465
dev.igc.0.queue_tx_0.txd_head: 465
dev.igc.0.queue_tx_0.interrupt_rate: 20832
dev.igc.0.fc_low_water: 32752
dev.igc.0.fc_high_water: 32768
dev.igc.0.rx_control: 71335938
dev.igc.0.device_control: 1075578433
dev.igc.0.watchdog_timeouts: 0
dev.igc.0.rx_overruns: 0
dev.igc.0.link_irq: 3
dev.igc.0.dropped: 0
dev.igc.0.eee_control: 1
dev.igc.0.tso_tcp_flags_mask_last_segment: 3967
dev.igc.0.tso_tcp_flags_mask_middle_segment: 3958
dev.igc.0.tso_tcp_flags_mask_first_segment: 4086
dev.igc.0.dmac: 0
dev.igc.0.rs_dump: 0
dev.igc.0.reg_dump: General Registers
CTRL 401c0641
STATUS 00380683
CTRL_EXIT 100000c0
Interrupt Registers
ICR 00000001
RX Registers
RCTL 04408002
RDLEN 00004000
RDH 00000200
RDT 000001ff
RXDCTL 02040808
RDBAL 750b0000
RDBAH 00000000
TX Registers
TCTL a503f0fa
TDBAL 750ac000
TDBAH 00000000
TDLEN 00004000
TDH 000001d3
TDT 000001d3
TXDCTL 0201011f
TDFH 00000000
TDFT 00000000
TDFHS 00000000
TDFPC 00000000
dev.igc.0.fc: 3
dev.igc.0.debug: -1
dev.igc.0.fw_version: EEPROM V2.32-0 eTrack 0x80000422
dev.igc.0.enable_aim: 1
dev.igc.0.nvm: -1
dev.igc.0.iflib.rxq3.rxq_fl0.buf_size: 2048
dev.igc.0.iflib.rxq3.rxq_fl0.credits: 1023
dev.igc.0.iflib.rxq3.rxq_fl0.cidx: 476
dev.igc.0.iflib.rxq3.rxq_fl0.pidx: 475
dev.igc.0.iflib.rxq3.cpu: 3
dev.igc.0.iflib.rxq2.rxq_fl0.buf_size: 2048
dev.igc.0.iflib.rxq2.rxq_fl0.credits: 1023
dev.igc.0.iflib.rxq2.rxq_fl0.cidx: 154
dev.igc.0.iflib.rxq2.rxq_fl0.pidx: 153
dev.igc.0.iflib.rxq2.cpu: 2
dev.igc.0.iflib.rxq1.rxq_fl0.buf_size: 2048
dev.igc.0.iflib.rxq1.rxq_fl0.credits: 1023
dev.igc.0.iflib.rxq1.rxq_fl0.cidx: 483
dev.igc.0.iflib.rxq1.rxq_fl0.pidx: 482
dev.igc.0.iflib.rxq1.cpu: 1
dev.igc.0.iflib.rxq0.rxq_fl0.buf_size: 2048
dev.igc.0.iflib.rxq0.rxq_fl0.credits: 1023
dev.igc.0.iflib.rxq0.rxq_fl0.cidx: 512
dev.igc.0.iflib.rxq0.rxq_fl0.pidx: 511
dev.igc.0.iflib.rxq0.cpu: 0
dev.igc.0.iflib.txq3.r_abdications: 0
dev.igc.0.iflib.txq3.r_restarts: 0
dev.igc.0.iflib.txq3.r_stalls: 0
dev.igc.0.iflib.txq3.r_starts: 3511869
dev.igc.0.iflib.txq3.r_drops: 0
dev.igc.0.iflib.txq3.r_enqueues: 3511901
dev.igc.0.iflib.txq3.ring_state: pidx_head: 1629 pidx_tail: 1629 cidx: 1629 state: IDLE
dev.igc.0.iflib.txq3.txq_cleaned: 7024679
dev.igc.0.iflib.txq3.txq_processed: 7024719
dev.igc.0.iflib.txq3.txq_in_use: 42
dev.igc.0.iflib.txq3.txq_cidx_processed: 79
dev.igc.0.iflib.txq3.txq_cidx: 39
dev.igc.0.iflib.txq3.txq_pidx: 81
dev.igc.0.iflib.txq3.no_tx_dma_setup: 0
dev.igc.0.iflib.txq3.txd_encap_efbig: 0
dev.igc.0.iflib.txq3.tx_map_failed: 0
dev.igc.0.iflib.txq3.no_desc_avail: 0
dev.igc.0.iflib.txq3.mbuf_defrag_failed: 0
dev.igc.0.iflib.txq3.m_pullups: 0
dev.igc.0.iflib.txq3.mbuf_defrag: 0
dev.igc.0.iflib.txq3.cpu: 3
dev.igc.0.iflib.txq2.r_abdications: 0
dev.igc.0.iflib.txq2.r_restarts: 0
dev.igc.0.iflib.txq2.r_stalls: 0
dev.igc.0.iflib.txq2.r_starts: 3448708
dev.igc.0.iflib.txq2.r_drops: 0
dev.igc.0.iflib.txq2.r_enqueues: 3448727
dev.igc.0.iflib.txq2.ring_state: pidx_head: 1943 pidx_tail: 1943 cidx: 1943 state: IDLE
dev.igc.0.iflib.txq2.txq_cleaned: 6897612
dev.igc.0.iflib.txq2.txq_processed: 6897652
dev.igc.0.iflib.txq2.txq_in_use: 46
dev.igc.0.iflib.txq2.txq_cidx_processed: 1012
dev.igc.0.iflib.txq2.txq_cidx: 972
dev.igc.0.iflib.txq2.txq_pidx: 1018
dev.igc.0.iflib.txq2.no_tx_dma_setup: 0
dev.igc.0.iflib.txq2.txd_encap_efbig: 0
dev.igc.0.iflib.txq2.tx_map_failed: 0
dev.igc.0.iflib.txq2.no_desc_avail: 0
dev.igc.0.iflib.txq2.mbuf_defrag_failed: 0
dev.igc.0.iflib.txq2.m_pullups: 0
dev.igc.0.iflib.txq2.mbuf_defrag: 0
dev.igc.0.iflib.txq2.cpu: 2
dev.igc.0.iflib.txq1.r_abdications: 0
dev.igc.0.iflib.txq1.r_restarts: 0
dev.igc.0.iflib.txq1.r_stalls: 0
dev.igc.0.iflib.txq1.r_starts: 3548794
dev.igc.0.iflib.txq1.r_drops: 0
dev.igc.0.iflib.txq1.r_enqueues: 3548797
dev.igc.0.iflib.txq1.ring_state: pidx_head: 1661 pidx_tail: 1661 cidx: 1661 state: IDLE
dev.igc.0.iflib.txq1.txq_cleaned: 7099415
dev.igc.0.iflib.txq1.txq_processed: 7099455
dev.igc.0.iflib.txq1.txq_in_use: 44
dev.igc.0.iflib.txq1.txq_cidx_processed: 63
dev.igc.0.iflib.txq1.txq_cidx: 23
dev.igc.0.iflib.txq1.txq_pidx: 67
dev.igc.0.iflib.txq1.no_tx_dma_setup: 0
dev.igc.0.iflib.txq1.txd_encap_efbig: 0
dev.igc.0.iflib.txq1.tx_map_failed: 0
dev.igc.0.iflib.txq1.no_desc_avail: 0
dev.igc.0.iflib.txq1.mbuf_defrag_failed: 0
dev.igc.0.iflib.txq1.m_pullups: 0
dev.igc.0.iflib.txq1.mbuf_defrag: 0
dev.igc.0.iflib.txq1.cpu: 1
dev.igc.0.iflib.txq0.r_abdications: 0
dev.igc.0.iflib.txq0.r_restarts: 0
dev.igc.0.iflib.txq0.r_stalls: 0
dev.igc.0.iflib.txq0.r_starts: 3652191
dev.igc.0.iflib.txq0.r_drops: 0
dev.igc.0.iflib.txq0.r_enqueues: 3652238
dev.igc.0.iflib.txq0.ring_state: pidx_head: 0654 pidx_tail: 0654 cidx: 0654 state: IDLE
dev.igc.0.iflib.txq0.txq_cleaned: 7304615
dev.igc.0.iflib.txq0.txq_processed: 7304655
dev.igc.0.iflib.txq0.txq_in_use: 44
dev.igc.0.iflib.txq0.txq_cidx_processed: 463
dev.igc.0.iflib.txq0.txq_cidx: 423
dev.igc.0.iflib.txq0.txq_pidx: 467
dev.igc.0.iflib.txq0.no_tx_dma_setup: 0
dev.igc.0.iflib.txq0.txd_encap_efbig: 0
dev.igc.0.iflib.txq0.tx_map_failed: 0
dev.igc.0.iflib.txq0.no_desc_avail: 0
dev.igc.0.iflib.txq0.mbuf_defrag_failed: 0
dev.igc.0.iflib.txq0.m_pullups: 3
dev.igc.0.iflib.txq0.mbuf_defrag: 0
dev.igc.0.iflib.txq0.cpu: 0
dev.igc.0.iflib.override_nrxds: 0
dev.igc.0.iflib.override_ntxds: 0
dev.igc.0.iflib.allocated_msix_vectors: 5
dev.igc.0.iflib.use_extra_msix_vectors: 0
dev.igc.0.iflib.use_logical_cores: 0
dev.igc.0.iflib.separate_txrx: 0
dev.igc.0.iflib.core_offset: 0
dev.igc.0.iflib.tx_abdicate: 0
dev.igc.0.iflib.rx_budget: 0
dev.igc.0.iflib.disable_msix: 0
dev.igc.0.iflib.override_qs_enable: 0
dev.igc.0.iflib.override_nrxqs: 0
dev.igc.0.iflib.override_ntxqs: 0
dev.igc.0.iflib.driver_version: 1
dev.igc.0.%iommu: rid=0x100
dev.igc.0.%parent: pci1
dev.igc.0.%pnpinfo: vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000 class=0x020000
dev.igc.0.%location: slot=0 function=0 dbsf=pci0:1:0:0
dev.igc.0.%driver: igc
dev.igc.0.%desc: Intel(R) Ethernet Controller I226-V
Cables?, and what devices are connected to these 226's?
Quote from: BrandyWine on July 15, 2026, 01:35:39 AMCables?, and what devices are connected to these 226's?
WAN connects to the ISP's modem/router device. LAN connects to a GrandStream GWN7801P switch. Cables are mostly CAT6. I can try swapping the LAN cable.
Here's what the switch has to say about the port:
Ethernet1/0/8 is up
Hardware is Gigabit Ethernet
Full-duplex, 1000Mb/s, media type is Copper
flow-control is off
back-pressure is enabled
selfloop-detection is disabled
selfloop-detection running is false
real time input rate 11986 bits/sec, 4 packets/sec
real time output rate 10192 bits/sec, 6 packets/sec
55595737 packets input, 73006841505 bytes, 0 throttles
Received 35574 broadcasts (69151 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame
69151 multicast, 0 pause input
27367707 input packets with dribble condition detected
32114150 packets output, 9685006492 bytes, 0 underrun
0 output errors, 0 collisions
0 babbles, 0 late collision, 0 deferred
0 PAUSE output
And OPNSense:
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAN (lan)
options=48420b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWTSO,HWSTATS,MEXTPG>
ether 64:62:66:24:f8:27
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
groups: InternalIFs TrustedIFs
media: Ethernet 1000baseT <full-duplex>
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
igc1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (wan)
options=48420b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWTSO,HWSTATS,MEXTPG>
ether 64:62:66:24:f8:28
inet 10.0.0.166 netmask 0xffffff00 broadcast 10.0.0.255
media: Ethernet 1000baseT <full-duplex>
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Anyone can correct me,..... IIRC the ASPM issue actually drops link. Does the switch logs ever show the link dropped off?
Have you tried a ping test from the FW itself, background a continuous ping to the FW's WAN DFG directed into a file, and then another to a IP on the LAN. Then after the problem happens kill those pid's and read the files.
ping 8.8.8.8 > wan.txt &
ping 192.168.1.50 > lan.txt &
wait for issue
killall ping
read the files.
There's also simple way to watch the power state for link. Need to start doing more deeper troubleshooting to find the issue BEFORE applying random fixes.
Yeah, I've never been entirely convinced that my issue is the same as the "usual" issue people seem to have with the I226-V, in part because of the lack of visible link flapping. I'm not a network engineer though... part of my motivation for setting this up was educational. I didn't expect to get hit with such an esoteric issue up front though, heh.
I'll try the ping test and see where that takes me.
Quote from: meyergru on July 14, 2026, 09:43:14 AM1. There are chip revisions (e.g., the latest ones have a smaller structure width and consume less power). You can see that via " pciconf -lv | grep -B3 igc", look at the "rev" value (mine is 0x04 on my current china box, I have others with 0x03).
Mine is rev 04.
Already on the latest available coreboot from Protectli (has no in-BIOS ASPM options), but I added the following tunables:
hw.pci.enable_aspm=0
dev.igc.0.eee_control=0
dev.igc.1.eee_control=0
dev.igc.2.eee_control=0
dev.igc.3.eee_control=0
Just a note to anyone adding the EEE tunables, your NICs may lock up when you apply them. Mine did. With the serial console I was able to see the following in dmesg:
[5872] igc1: link state changed to DOWN
[5876] igc1: link state changed to UP
[5876] igc1: link state changed to DOWN
[5880] igc1: link state changed to UP
[5996] igc1: link state changed to DOWN
[5999] igc1: link state changed to UP
[6042] igc1: link state changed to DOWN
[6046] igc1: link state changed to UP
[6047] igc1: link state changed to DOWN
[6048] wg1: loop detected
[6048] wg1: loop detected
A reboot command from console brought everything online again.
Will see how it goes with this configuration (mind: still on the original 2.13 NVM) however early indication is that there is no improvement. Still getting sporadic dpinger losses on the gateways.
The 'igc_aspm' test kernel is still active.
That really looks like link flapping to me which may indicate a flaky connection to your modem or ONT.
Hmm, I don't have those messages typically. Only saw them after applying the tunables and now they're gone, but now that you mention, I will try a cable swap to the modem.
In rare cases it might also be caused by the counterpart because of slight incompatibilities (or settings, like different flow control or speed/duplex).
Quote from: fornax on July 14, 2026, 09:43:49 PMUnfortunately the -igc_aspm kernel didn't resolve my issue. It happened again this morning, and as usual bouncing the LAN interface with ifconfig down/up resolved it. There's nothing interesting in dmesg and the only recent entries in the syslog relate to a DHCP renewal for the WAN interface (which is not something I've seen in other instances).
One more thing to try before I'm going to suggest a more complicated troubleshooting setup to help classify the issue:
Disable flow control on all igc ports through System -> Settings -> Tunables. Tunable: "dev.igc.X.fc", Value: "0" (where X is the port). For 4 ports I'd expect 4 entries.
Quote from: OPNenthu on July 15, 2026, 09:06:13 AMhw.pci.enable_aspm=0
dev.igc.0.eee_control=0
dev.igc.1.eee_control=0
dev.igc.2.eee_control=0
dev.igc.3.eee_control=0
Where did you get "0" for EEE? Online docs show that for igc the logic is backwards.
online ref:
EEE settings on FreeBSD can be managed using sysctl commands, specifically hw.igc.eee_setting to enable or disable Energy Efficient Ethernet on the adapter, and dev.igc.0.eee_control for individual interfaces. Both settings should be set to 1 to disable EEE.Do your igc's have any counts for eee ?
sysctl -a | grep "eee"
specifically the rx and tx lpi counters
As for an igc lockup after eee settings, I did not experience that, but I had updated NVM prior to doing the additional tuning. Always best to start with updated hardware (uefi/bios NVM etc) before doing the upper layer OS install, or, do NVM updating from OS but before doing fine tuning.
Thanks, I hadn't really looked up the EEE sysctls. Think I copied from somewhere. Will change them and check the counter.
---
EDIT: Per the igc man page (https://man.freebsd.org/cgi/man.cgi?amp&format=html&query=igc&sektion=4) it's disabled by default for all interfaces:
Quotehw.igc.eee_setting
Disable or enable Energy Efficient Ethernet. Default 1 (dis-
abled).
So I just removed those interface-level 'eee' tunables, as it was before. Post reboot:
$ sysctl -a | grep "eee"
hw.bxe.autogreeen: 0
hw.igc.eee_setting: 1
hw.em.eee_setting: 1
dev.igc.3.eee_control: 1
dev.igc.2.eee_control: 1
dev.igc.1.eee_control: 1
dev.igc.0.eee_control: 1
Quote from: tuto2 on July 15, 2026, 11:24:07 AMOne more thing to try before I'm going to suggest a more complicated troubleshooting setup to help classify the issue:
Disable flow control on all igc ports through System -> Settings -> Tunables. Tunable: "dev.igc.X.fc", Value: "0" (where X is the port). For 4 ports I'd expect 4 entries.
Ok, I had those in when I was tinkering with tunables initially, I'll try adding them back into the current state (just 2 interfaces here).
What's the status of 'igc' related changes in the kernel shipped with 26.7? Do we still need to patch post upgrade?
EEE is disabled. It's not an ASPM or EEE issue.
NVM 2.32 fixes a lane swapping issue, which can present issues like link working ok now and then fails later.
NVM 2.32 - Fixes an issue in MDI lane swap handling that caused the P (positive) and N (negative) signal polarities to be swapped incorrectly.
The buggy lane swapping can occur for numerous reasons.
Hard to follow which user has what NVM, but the base config needs to be i226 with latest NVM.
Quote from: OPNenthu on July 16, 2026, 02:48:10 AMWhat's the status of 'igc' related changes in the kernel shipped with 26.7? Do we still need to patch post upgrade?
The kernel patches have not been shipped. Neither patch confirmed or solved anything, there's also no custom kernel for these patches on the 26.7 ABI.
Ok, turning off flow control and swapping the LAN-side cable didn't change anything. As we're 5 pages in and have multiple setups being talked about, I'm going to sort of "reboot" the OP:
Symptoms are one or more of the following:
- Games (particularly GTA Online, but I suspect I also had an issue with the online features of Death Stranding at one point) unable to contact servers.
- Sites (most or all) not loading on first attempt, but 10-20 seconds later retrying is successful.
- DHCP stops working. Something I've found since I started this thread is that it seems to happen on some VLANs but not all at once, and the VLANs that do/don't work aren't the same in every incident.
- There are NO link flaps noted in dmesg/syslog other than the ones I force to fix the issue.
The only thing that ties these issues together is that they're all fixed by bouncing the firewall's LAN interface (ifconfig igc0 down && ifconfig igc0 up).
Current state:
OPNSense was last updated 7/12 (version 26.1.11_6). Kernel is the -igc_aspm kernel first mentioned in post #17. i226-V NVM version on both interfaces is 2.32. LAN link is statically set to 1000Mbps full duplex, FC off on both ends. The only tunables set are dev.igc.0.fc=0 and dev.igc.1.fc=0.
Things I've tried so far in this thread:
- Various tunables mentioned in the OP.
- The -iflib kernel mentioned in post #2 and the -igc_aspm kernel.
- Swapping the LAN-side cable.
- Updating the NVM from stock 2.17 to current 2.32.
Currently the system is experiencing the issue in that I'm getting the usual error preventing me from playing GTA Online and DHCP is not working on one VLAN. I'm going to leave it in this state for a while to troubleshoot since most everything else is still working. If anyone has any other suggestions, I'm all ears. Thanks for the guidance so far.
Oh, and I've had continuous pings running from the firewall both to the LAN and WAN, and both are still happily plugging away with 100% return.
Well, to complicate matters it looks like there's a separate issue with dnsmasq. Although in the past I've definitely run into VLANs losing DHCP which was solved with an interface bounce, this particular incident appears to be something else. It was not solved by bouncing the interface. (dnsmasq is throwing "no address range available for DHCP request via vlan01" despite vlan01 being in the interfaces list and having a range assigned.)
Still open to further suggestions, but I'm now leaning toward starting from scratch with a reinstall of OPNSense.
A kernel patch related to your issue has been developed, assuming you're on 26.1.11_6, you can install it with:
# opnsense-update -zkr 26.1.11-igc
and reboot.
Otherwise if you're on 26.7:
# opnsense-update -zkr 26.7-igc
Relevant events should be logged in System -> Log Files -> General. Can you share these here?
Quote from: fornax on July 16, 2026, 11:25:09 PMI'm going to sort of "reboot" the OP:
Symptoms are one or more of the following:
- Games (particularly GTA Online, but I suspect I also had an issue with the online features of Death Stranding at one point) unable to contact servers.
Currently the system is experiencing the issue in that I'm getting the usual error preventing me from playing GTA Online
May I suggest not involving this game into these issues ?
My connection has always been working just fine across multiple Routers and that stupid P2P game still finds a way to spit out similar issues to yours for some dumb reason... :(
And now that they have released the new DLC a couple of days ago I bet the issues are even worse than before !!
Quote from: tuto2 on July 17, 2026, 11:50:59 AM# opnsense-update -zkr 26.7-igc
Will the official patch be included in the next update?
Not until we know what's going on.
Quote from: fornax on July 16, 2026, 11:25:09 PMSymptoms are one or more of the following:
- Games (particularly GTA Online, but I suspect I also had an issue with the online features of Death Stranding at one point) unable to contact servers.
- Sites (most or all) not loading on first attempt, but 10-20 seconds later retrying is successful.
- DHCP stops working. Something I've found since I started this thread is that it seems to happen on some VLANs but not all at once, and the VLANs that do/don't work aren't the same in every incident.
- There are NO link flaps noted in dmesg/syslog other than the ones I force to fix the issue.
The only thing that ties these issues together is that they're all fixed by bouncing the firewall's LAN interface (ifconfig igc0 down && ifconfig igc0 up).
Well, that's poor analysis as-is.
No indicators if your issue is WAN or LAN side.
DHCP stops working, so just for the LAN side?
VLANs? How do you mean? Two i226's and VLAN's on LAN side, so you run .1q or your VLAN's are L3 ?
If there's no indicator that the i226 link goes down, then perhaps it is working normally.
Can you SSH into the FW using a non i226 iface? I suggest you do that and start monitoring stuff. Run a ping to the FW LAN IP address, then wait for the no-traffic issue to arise, what does the ping show?
Start a 2nd ssh session, then
dmesg -w | grep -E 'igc'
see if any kernel messages arrive when your issue happens.
Quote from: tuto2 on July 17, 2026, 11:50:59 AMA kernel patch related to your issue has been developed, assuming you're on 26.1.11_6, you can install it with:
# opnsense-update -zkr 26.1.11-igc
Sure, I'll install that now. What's the change(s) in this one?
Quote from: nero355 on July 17, 2026, 01:54:15 PMMay I suggest not involving this game into these issues ?
Yeah, I know the game is buggy as hell. If it was the only issue I was having I wouldn't be here. But it's a useful canary; as I usually check into the game fairly early, it's often my first indication that something's going wrong. And the fact that bouncing the LAN interface on the firewall makes it immediately start working again (and the fact that I never had these issues before switching to the new firewall) leads me to believe this particular issue isn't the game's fault.
Quote from: BrandyWine on July 17, 2026, 07:43:41 PMNo indicators if your issue is WAN or LAN side.
I haven't dug too much into the WAN side because only bouncing the LAN interface has any effect. I've tried bouncing WAN first on a few occasions and it never changes anything.
QuoteDHCP stops working, so just for the LAN side?
Yes, the firewall's DHCP client works just fine, it's the LAN-side clients on one or more VLANs that stop working.
QuoteVLANs? How do you mean? Two i226's and VLAN's on LAN side, so you run .1q or your VLAN's are L3 ?
Yes, 802.1q VLANs on the LAN side only.
QuoteCan you SSH into the FW using a non i226 iface? I suggest you do that and start monitoring stuff. Run a ping to the FW LAN IP address, then wait for the no-traffic issue to arise, what does the ping show?
Start a 2nd ssh session, then
dmesg -w | grep -E 'igc'
see if any kernel messages arrive when your issue happens.
The firewall has just the two i226-Vs. I could set it up to run in the background like the previous one, though. FreeBSD's dmesg doesn't appear to have a follow option, but neither dmesg nor the syslog have never shown any indication that they see anything wrong anyway.
https://github.com/opnsense/src/commit/effb6c32ae
It changes the direct driver reset calls to mimmic the way down/up works in practice. It also adds debug output to see which reset is the one that causes the intermittent issues during normal operation where one doesn't directly force the error (e.g. when you have a eee_control sysctl set and hit apply for tunables it can influence the driver directly, or how the driver otherwise reacts to link changes initiated by a connected switch for example).
Cheers,
Franco
I am not sure if .1q tagging in i226 is good or not. Best to always run latest NVM.
but this note below. Try disabling vlan tagging from offloading, this brings it back to kernel.
ifconfig igc0 -vlanhwtag -vlanhwtso -vlanhwcsumWhere igc0 is your LAN port, but change it as needed.
See if that helps.
Known Issues with Intel I226-V NICs and VLAN Tagging
VLAN Tagging Offload Problems
There are several reported issues when using Intel I226-V Network Interface Cards (NICs) for VLAN tagging offload:
Untagged Traffic Works: While untagged traffic typically functions without issues, tagged traffic often fails or is missing.
Intermittent Functionality: In some configurations, tagged networks may work intermittently or only under low load conditions. This can lead to unreliable network performance.
DHCP and Guest Traffic Issues: Problems are frequently observed with DHCP requests and guest traffic not functioning correctly across VLANs.
I did have another incident with the -igc kernel the other day (attempted to post about it with logs but it looks like it didn't go through?). There were no syslog events associated with anything other than the reboot after installing the kernel or the manual interface bounce.
Quote from: BrandyWine on July 21, 2026, 07:10:49 AMTry disabling vlan tagging from offloading, this brings it back to kernel.
ifconfig igc0 -vlanhwtag -vlanhwtso -vlanhwcsum
Interesting find and definitely worth a try, doing that now.
Quote from: fornax on July 22, 2026, 12:37:30 AMInteresting find and definitely worth a try, doing that now.
Considering log data on fw or switch does not seem to indicate link down issue, then something else has to be causing the issue which appears to act like link down. Take for example if the switch still has good ARP and CAM entries it will indeed write the frame to L1, the Rx on other end may get it, but from there it get's ignored or lost.
Offloading is something to investigate.
I do have another ubuntu device that uses i226v's and one port is a dedicated sniffer port, I have vlan SPAN from the switch, packets come in .1q tagged, but I do use offloading because the N150 cpu is already busy with other things. I have not experienced an issue with this config. I use the latest 226 NVM, and also latest igc from the ubuntu 24.04lts repo.
Well, drivers don't log that much data in general. Another test kernel has been made available which includes disabling ASPM, a cleanup of some suspicious spots and more verbose logging (but not disruptive). If anyone is on version 26.1.x and wants to test:
# opnsense-update -zkr 26.1.11-igc2
and reboot.
Again, the timestamp of a failure and the relevant "System -> Log Files -> General" snippet of the same time is most relevant here.
Edit: kernel for 26.7 is up as well:
# opnsense-update -zkr 26.7-igc2
Quote from: tuto2 on July 23, 2026, 01:27:50 PMEdit: kernel for 26.7 is up as well:
# opnsense-update -zkr 26.7-igc2
I'm happy to try this as I'm on 26.7 now but I'm not sure if my symptoms indicate me as a test candidate. After re-reading @fornax's posts and #62 especially, I think you guys might be targeting a different set of issues than I have. It's been hard to tell.
Do you have field complaints other than this thread? Would you be open to setting up a "Call for testing" thread with a description of the specific problem(s) that the OPNsense team is targeting, a description of who is/isn't a test candidate, etc.?
This is a good read, seems more like router tuning.
https://docs.opnsense.org/manual/interfaces_settings.html
What's the status of your fix?
First time for everything, I guess... yesterday I had an issue that was only resolved after bouncing the WAN interface instead of LAN like every other time. In a fit of frustration I reinstalled the OS today, so it's on a fresh 26.7. That should rule out OS corruption or weird config issues from me tinkering with things. I also installed the -igc2 kernel. Will continue to monitor.
Quote from: fornax on July 27, 2026, 02:05:14 AMFirst time for everything, I guess... yesterday I had an issue that was only resolved after bouncing the WAN interface instead of LAN like every other time. In a fit of frustration I reinstalled the OS today
And you are running latest NVM for the 226's ?
Quote from: BrandyWine on July 27, 2026, 05:47:40 PMAnd you are running latest NVM for the 226's ?
As of post #29, yes.
So the WAN "died", and then you installed fresh copy of 26.7? That's not really a good troubleshooting tactic, because now the issue (if it still exists) is reset.
Is WAN router or LAN switch 2.5G capable?
Even on 15.1 (26.7), verify EEE settings and look for events.
ethtool --show-eee igc0
ethtool -i igc0
and
nohup sh -c "dmesg -aw | grep -i -E 'igc|eee|energy|lpi|sleep|wake'" > watch-energy.txt 2>&1 &
its wrapped nohup so if your ssh dies the capture keeps running, you come back in to look at the txt file, etc. Kill that pid when done.
Quote from: BrandyWine on July 27, 2026, 09:09:16 PMethtool --show-eee igc0
ethtool -i igc0
root@opnsense:~ # ethtool
ethtool: Command not found.
OPNsense isn't Linux.
Quote from: BrandyWine on July 27, 2026, 09:09:16 PMSo the WAN "died", and then you installed fresh copy of 26.7? That's not really a good troubleshooting tactic, because now the issue (if it still exists) is reset.
I wanted to rule out corruption in the install. Also, as this was my first experience with OPNSense, I did a fair amount of poking around and playing with settings, so I wanted a fresh start to rule out any possibility of lingering config weirdness. And those are ruled out now, as I had another incident last night.
QuoteIs WAN router or LAN switch 2.5G capable?
WAN router yes, LAN switch no.
QuoteEven on 15.1 (26.7), verify EEE settings and look for events.
root@scutum:~ # sysctl -a | grep igc | grep eee
hw.igc.eee_setting: 1
dev.igc.1.eee_control: 1
dev.igc.0.eee_control: 1
dmesg and syslog have never shown any random events. Everything is associated with bootup, manual interface bounces, or other actions on my part (eg config changes).
Quote from: Patrick M. Hausen on July 27, 2026, 09:47:01 PMQuote from: BrandyWine on July 27, 2026, 09:09:16 PMethtool --show-eee igc0
ethtool -i igc0
root@opnsense:~ # ethtool
ethtool: Command not found.
OPNsense isn't Linux.
Yeah, my bad, I do that often. I live in ubuntu for last 12mo, deep in interface settings with both wired and wireless IDS.
@fornax, it has been seen in past that auto-negotiate for 2.5gbps was an issue between certain devices that can do 2.5Gbps. If the WAN shows problem again, try:
sudo ifconfig igc1 down
sudo ifconfig igc1 media 1000baseTX
sudo ifconfig igc1 up
Then monitor.
Quote from: BrandyWine on July 28, 2026, 07:53:03 AM@fornax, it has been seen in past that auto-negotiate for 2.5gbps was an issue between certain devices that can do 2.5Gbps. If the WAN shows problem again, try:
sudo ifconfig igc1 down
sudo ifconfig igc1 media 1000baseTX
sudo ifconfig igc1 up
Yeah, I actually had both interfaces hardcoded to 1000 Full before the rebuild, thanks for the reminder.
I also flashed the BIOS from coreboot to AMI, which was a suggestion Protectli threw out there when I contacted them previously.
Wanted to drop in a status update. I'm not ready to declare victory quite yet, but this is the longest I've gone without an incident in quite a while. Possibly it was an issue with coreboot? Fingers crossed. I'll give it another week and then consider this resolved.
Quote from: fornax on August 04, 2026, 07:03:27 PMWanted to drop in a status update. I'm not ready to declare victory quite yet, but this is the longest I've gone without an incident in quite a while. Possibly it was an issue with coreboot? Fingers crossed. I'll give it another week and then consider this resolved.
I am also running a Protectli (VP2420) with I226-V NICs and AMI-Bios and never had any stability problems. While I like the idea of coreboot as an open source solution, I have never used it on my two Protectli units and issues like the one you describe make me even less likely to try it in the future.
I'm not aware of a widespread issue with coreboot but then again I don't have a Reddit account. Who knows what's out there :-/
It's weird that Protectli support tell people to use AMI as coreboot is one of the main selling points and something they recommend.
We don't have a clear picture. @fornax did you get any statement from them about this? Are they even working with you to diagnose and root cause, or just pushing you to AMI?
Quote from: OPNenthu on August 04, 2026, 10:44:55 PM@fornax did you get any statement from them about this? Are they even working with you to diagnose and root cause, or just pushing you to AMI?
The only time I've reached out to them so far was specifically about the NVM update, but I did summarize the issue, so they did respond to that as well. And I'm glad you mentioned that, because looking back at the email I realize I misread it initially and probably should have tried this sooner. The relevant part is:
QuoteAt this point we have seen similar behavior in the VP3200 series' coreboot implementation compared to the VP2440's. The VP2440 had a NIC throughput degradation issue that was related to ASPM. (https://kb.protectli.com/wp-content/uploads/sites/9/2026/02/TSB-2025-001_VP2440-ASPM-Network-Interface-Performance-Issue-v2_0.pdf) Our other products don't seem to display this behavior.
I missed that they've actually seen "similar behavior" in my model as in the VP2440, which had a coreboot issue that required an update. So that's entirely on me, I should have pursued that at the time. I was initially going to wait until I considered this resolved and then reach back out to let them know, but I'm accelerating that now.
Quote from: fornax on August 04, 2026, 11:59:00 PMI was initially going to wait until I considered this resolved and then reach back out to let them know, but I'm accelerating that now.
Thanks for sharing the statement but please don't rush on account of my asking about it. It's good to know if your issue truly is resolved by switching to AMI (and no other factors).
Ok, it's been 2 weeks without incident, so I'm going to (cautiously) call this resolved by the switch from coreboot BIOS to AMI. I did update Protectli; they indicated there's no plan for a patch to coreboot for the VP3200 series at this time. The support person mentioned they wanted to talk to the dev team about it, but I haven't heard anything in the week since, so I'm assuming nothing further is forthcoming. I'll update this if that changes.
Thanks to everyone who pitched in with troubleshooting help and suggestions!
Quote from: fornax on August 12, 2026, 05:35:47 PMThe support person mentioned they wanted to talk to the dev team about it, but I haven't heard anything in the week since, so I'm assuming nothing further is forthcoming. I'll update this if that changes.
Just wanted to leave a thanks for making upstream aware of these issues. Maybe some more updates (or at least clarity) will trickle down into coreboot eventually.
There are some patches in 26.7.2 that should improve stability of igc regardless of firmware version.
Cheers,
Franco
@franco would those changes have any bearing on TLS handshake hangups? For example in Firefox I'd see this in the lower left corner very often and it would take seconds to resolve, or sometimes require a refresh:
Screenshot from 2026-08-05 16-29-05.png
Currently on 26.7.2 and no lie, I'm not seeing this yet.
I'll temper my excitement but should I be cautiously optimistic, or is this placebo?
EDIT: I had already ruled out an MTU issue. My DOCSIS gateway and WAN interface use the default 1500 and I confirmed with ping from my Linux client that I can send up to 1472 bytes of ICMP payload with the "don't fragment" flag set:
$ ping -c 3 -M do -s 1472 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
1480 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=32.3 ms
1480 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=39.2 ms
1480 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=36.2 ms
$ ping -c 3 -M do -s 1473 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1473(1501) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
> would those changes have any bearing on TLS handshake hangups? For example in Firefox I'd see this in the lower left corner very often and it would take seconds to resolve, or sometimes require a refresh:
Could be, but hard to prove. The igc behaviour was quite erratic.
Cheers,
Franco
Although I can't prove it with data, the update did something. This is the first time in a long while (maybe since I still had my Asus router) that I am not seeing delays when loading pages.
I still have the sporadic packet loss in dpinger as I posted earlier (https://forum.opnsense.org/index.php?topic=52253.msg269997#msg269997) but I'm now chalking that up to an ISP or cable infrastructure issue.