[solved] Intel i226 Firmware (see post #39)

[OPNenthu]

So now that I'm thoroughly paranoid about whether or not mine has an issue... how can I know?  Is there a specific symptom that the i226v exhibits and how do we measure it?

Code Select Expand

[1] igc3: <Intel(R) Ethernet Controller I226-V> mem 0x91200000-0x912fffff,0x91300000-0x91303fff at device 0.0 on pci5
[1] igc3: EEPROM V2.13-0 eTrack 0x80000286

I understand the sentiment that "if it isn't broken, don't fix it," but this is fuzzy.  Maybe those sporadic internet glitches that I tolerate are not normal?... or are they?

[meyergru]

I had 2.13 as well and no problems. apart from network ports freezing when ASPM was enabled. I think that this is not a NIC-specific problem, however, because the freezes occured the same with my Intel 82559ES NICs with ASPM enabled.

I now updated to 2.32 and also: no problems.

This method might fix some glitches for people with 2.17.

[ProximusAl]

Well, that was scary, but I've successfully updated all mine from EEPROM V2.17-0 eTrack 0x80000308 to EEPROM V2.32-0 eTrack 0x80000425.

I used the reboot.sh method for the in use NIC's which worked *perfectly*.

Everything seems to be great.....

Thanks everyone for this extremely useful post.....

[bubbyboyy]

Updated all 6 nics from 2.13 to 2.32 using the 2mb bin.

That was a wild ride, and my heart is still pounding. I feel the need for a stiff drink after that.

Even though I was not experiencing any problems, I'm not sure what is the benefit is?

Thanks all.

Code Select Expand

root@OPNsense:~ # dmesg | grep igc
[1] igc0: <Intel(R) Ethernet Controller I226-V> mem 0x81400000-0x814fffff,0x81500000-0x81503fff 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: Ethernet address: a8:b8:e0:0a:14:dd
[1] igc0: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igc1: <Intel(R) Ethernet Controller I226-V> mem 0x81100000-0x811fffff,0x81200000-0x81203fff 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: Ethernet address: a8:b8:e0:0a:14:de
[1] igc1: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igc2: <Intel(R) Ethernet Controller I226-V> mem 0x80e00000-0x80efffff,0x80f00000-0x80f03fff at device 0.0 on pci3
[1] igc2: EEPROM V2.32-0 eTrack 0x80000422
[1] igc2: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc2: Using 4 RX queues 4 TX queues
[1] igc2: Using MSI-X interrupts with 5 vectors
[1] igc2: Ethernet address: a8:b8:e0:0a:14:df
[1] igc2: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igc3: <Intel(R) Ethernet Controller I226-V> mem 0x80b00000-0x80bfffff,0x80c00000-0x80c03fff at device 0.0 on pci4
[1] igc3: EEPROM V2.32-0 eTrack 0x80000422
[1] igc3: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc3: Using 4 RX queues 4 TX queues
[1] igc3: Using MSI-X interrupts with 5 vectors
[1] igc3: Ethernet address: a8:b8:e0:0a:14:e0
[1] igc3: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igc4: <Intel(R) Ethernet Controller I226-V> mem 0x80800000-0x808fffff,0x80900000-0x80903fff at device 0.0 on pci5
[1] igc4: EEPROM V2.32-0 eTrack 0x80000422
[1] igc4: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc4: Using 4 RX queues 4 TX queues
[1] igc4: Using MSI-X interrupts with 5 vectors
[1] igc4: Ethernet address: a8:b8:e0:0a:14:e1
[1] igc4: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igc5: <Intel(R) Ethernet Controller I226-V> mem 0x80500000-0x805fffff,0x80600000-0x80603fff at device 0.0 on pci7
[1] igc5: EEPROM V2.32-0 eTrack 0x80000422
[1] igc5: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc5: Using 4 RX queues 4 TX queues
[1] igc5: Using MSI-X interrupts with 5 vectors
[1] igc5: Ethernet address: a8:b8:e0:0a:14:e2
[1] igc5: netmap queues/slots: TX 4/1024, RX 4/1024
[7] igc1: link state changed to UP
[7] igc2: link state changed to UP
[7] igc3: link state changed to UP
[7] igc4: link state changed to UP
[7] igc5: link state changed to UP
[14] igc2: link state changed to DOWN
[14] igc3: link state changed to DOWN
[14] igc4: link state changed to DOWN
[14] igc5: link state changed to DOWN
[14] igc1: link state changed to DOWN
[17] igc2: link state changed to UP
[18] igc1: link state changed to UP
[18] igc5: link state changed to UP
[18] igc4: link state changed to UP
[18] igc2: promiscuous mode enabled
[18] igc3: promiscuous mode enabled
[18] igc4: promiscuous mode enabled
[18] igc5: promiscuous mode enabled
[18] igc0: promiscuous mode enabled
[22] igc3: link state changed to UP
root@OPNsense:~ #


[BrandyWine]

Is updating to nvm v2.32 of great benefit?
Well, the best docs to get at are inside Intel protected area, so you need a developer account. I tried to register, my request was not approved.

With all the digging online I came across reports of issues related to nvm 2.17. Some of those said they updated and their issue went away. Most of what I read was iface dropping off under high bandwidth use. The exact scenario (settings, device use, etc) were not in those posts, it was more just chatter about the nvm.

Without all the detailed release notes, we can apply a little logic. I don't know anyone taking time to build an updated firmware image just for fun. Updates are usually a feature add and-or a fix. This applies to device firmware and drivers. freeBSD 14.3 did have an update in igc driver, so we expect that version to be "the latest" for 14.3, and Billy Curtis has v2.32 bin firmware, presumably the latest Intel bin.

Running latest driver with latest firmware is usually the best match. Sometimes you get new bugs related to a new feature, sometimes just a new bug from updated code, and sometimes no issue at all. But we should expect the updated stuff to be have fixes for previous known bugs.

As for power control, there's something called an Optionality bit which can completely disable ASPM. I not sure where that is just yet, but I also do not fully understand the ASPM issue. I did read that on some (some) platforms/OS the power policy was just too aggressive and would send signal to a device to enter into L0s power state when by no means it should start power savings. Perhaps there are rare setups where a LAN side port goes 100% idle so the power savings kicks in, but WAN port is always active with OPNsense, and probably 99.9% of devices have active LAN ports, thus these devices should never power save. And, from what I read about ASPM, the L0s state should not cause any 100% packet loss.

Without wrapping some processes in debug/monitor its hard to know for sure what's going on. Which is something I don't have time to do right now, and, I already updated nvm.

So now we wait to see who brings the 1st nic related issue with nvm v2.32. Mine has been stable.

   

[BrandyWine]

I used the reboot.sh method for the in use NIC's which worked *perfectly*.

For readers, it's always best to do your 1st flash to a nic that is not the nic you use for ssh. This way you can make sure all your flash settings are good. After all the others are completed then do nic you are using for ssh, using the reboot script, etc. Never start with the nic you are ssh'd into (if it's the only nic that allows ssh, etc), because if it goes badly then you might have bricked it.

As a side note, when I flashed my un-used nic and moved my WAN cable there, the connection did not come up fully. I did have to reboot my cable modem. I suspect a glitch in DHCP, but glitch on modem side, WAN iface did not get v4/v6 IP. After modem reboot everything was fine.

Another caveat for some might be this. Some internet services (think gmail and such) may have marked your access there as "trusted" based on long use of one source IP. When you move WAN connection to a new nic (new MAC) the DHCP from ISP may hand out a completely different IP than before, and then your access to those internet services may change away from "trusted", making you re-validate yourself. gmail and yahoo is notorious for this, and it's a royal pita.

For the most part, it's ok to just leave your connections (cables) as-is and just flash the nics in proper sequence. I moved my WAN cable only because I wanted to play around flashing on an unused nic.