Periodic NIC issues (?) with Protectli Vault, Intel i226-V

[BrandyWine]

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?

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

[fornax]

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?

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:

Code Select Expand

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


[tuto2]

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:

Ok, getting closer..

Can you try:

Code Select Expand

# opnsense-update -zkr 26.1.11-igc_aspm

and reboot?

Ref: https://github.com/freebsd/freebsd-src/pull/2318

[tuto2]

Hold up...

Code Select Expand

dev.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.

[Greg_E]

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.

[BrandyWine]

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.

When 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.

[franco]

@Greg_E the kernel mentioned above is also on the business mirror to try.


Cheers,
Franco

[fornax]

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.

[OPNenthu]

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.

[fornax]

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.

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.)

[OPNenthu]

(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:

Code Select Expand

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:

Code Select Expand

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 :)

[BrandyWine]

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. ;)

[BrandyWine]

I 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.

[OPNenthu]

What 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.

t'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.

[fornax]

Thanks 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:

Code Select Expand

[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/1024
I 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.