Intel i225/i226 2.5G NIC Information/Issue Tracking Thread

[BrandyWine]

Did updating 226-V firmware helped to resolve connection issues?
All 5 my adaptors are currently on ver. 2.22 and I'm not sure it's worth to update...
I'm just started to test OPNsense on a new box and have experienced a few times LAN port stopped responding and needed to change the port(in a lan-bridge) to reconnect.

I had read v2.17 is where all the issues are. I am not sure yet how far past v2.17 is good, v2.32 is available. I mentioned in another thread, if Intel took time & effort to build new firmware, then they didn't do it for no reason. Also see the "Intel i226 Firmware" thread.

Can you post some data for your igc 226-V

1) pciconf -lV
2) dmesg |grep igc

[blackie333]

pciconf -lV

OK, you can see the commands results below (selected lines only)

Code Select Expand

1) pciconf -lV
igc0@pci0:2:0:0:        class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
igc1@pci0:4:0:0:        class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
igc2@pci0:5:0:0:        class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
igc3@pci0:6:0:0:        class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
igc4@pci0:7:0:0:        class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000

2) dmesg |grep igc
[1] igc0: <Intel(R) Ethernet Controller I226-V> mem 0x81100000-0x811fffff,0x81200000-0x81203fff at device 0.0 on pci2
[1] igc0: EEPROM V2.22-0 eTrack 0x80000371
[1] igc1: <Intel(R) Ethernet Controller I226-V> mem 0x80e00000-0x80efffff,0x80f00000-0x80f03fff at device 0.0 on pci4
[1] igc1: EEPROM V2.22-0 eTrack 0x80000371
[1] igc2: <Intel(R) Ethernet Controller I226-V> mem 0x80b00000-0x80bfffff,0x80c00000-0x80c03fff at device 0.0 on pci5
[1] igc2: EEPROM V2.22-0 eTrack 0x80000371
[1] igc3: <Intel(R) Ethernet Controller I226-V> mem 0x80800000-0x808fffff,0x80900000-0x80903fff at device 0.0 on pci6
[1] igc3: EEPROM V2.22-0 eTrack 0x80000371
[1] igc4: <Intel(R) Ethernet Controller I226-V> mem 0x80500000-0x805fffff,0x80600000-0x80603fff at device 0.0 on pci7
[1] igc4: EEPROM V2.22-0 eTrack 0x80000371

[10] igc3: link state changed to UP
[101] igc3: link state changed to DOWN
[101] igc3: promiscuous mode enabled
[101] igc2: promiscuous mode enabled
[101] igc0: promiscuous mode enabled
[104] igc3: link state changed to UP


[BrandyWine]

That's odd output for that 226-V device. Showing a 2MB etid.
I need to look further. You can try flashing the 2.32 2MB to one of your unused 226's if you have unused. If it flashes in ok then you have 2MB version. If not then try the 1MB version of the bin.

[felipe0123]

Issue: Lots of RX errors / missed packets when the NIC is connected to Arris ONT Calix 711GE ONT, connecting it to switch or computer gives no error. Swapping igc0/igc1 makes no difference. So many pkts are missed that it will frequently look like DNS issues, due to missed SYN-ACKs and long delays to connect to websites.

Code Select Expand

# sysctl dev.igc.1.mac_stats.missed_packets
dev.igc.1.mac_stats.missed_packets: 15467

# netstat -I igc1 | head 2
Name    Mtu Network         Address                                           Ipkts  Ierrs  Idrop    Opkts  Oerrs   Coll
igc1   1500 <Link#4>        64:62:66:XX:XX:XX                               1298933  15597      0   629757      0      0



Device info:

Code Select Expand

# dmesg | grep '\[1\] igc'
[1] igc0: <Intel(R) Ethernet Controller I226-V> mem 0x80400000-0x804fffff,0x80600000-0x80603fff at device 0.0 on pci2
[1] igc0: EEPROM V2.17-0 eTrack 0x80000303
[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: 64:62:66:XX:XX:XX
[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 pci4
[1] igc1: EEPROM V2.17-0 eTrack 0x80000303
[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: 64:62:66:XX:XX:XY
[1] igc1: netmap queues/slots: TX 4/1024, RX 4/1024

# pciconf -lV | grep igc
igc0@pci0:2:0:0:    class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
igc1@pci0:4:0:0:    class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000

You will notice RSS enabled, I just enabled it for testing. It made no difference.


UPDATE: Inspired by another users' post, I picked up an old EdgeRoute, configured it as a dumb switch and put it in between opnsense and the OTN, RX errors dropped to zero
UPDATE2: updated one of the interfaces from V2.17-0 to V2.32-0 (2M). It did not fix the issue. Moved connection back to 2.17 with dumb switch
UPDATE3: after a couple days, family complained about transient connection issues. Although I can't see if there are RX errors on dumb switch interface there's none on opnsense interface, but lots of duplicate ACK just like before
UPDATE4: it tuned out the issues were caused by ASPM. I'm running OpnSense on Protectli V2440 + coreboot and interfaces would still have ASPM enabled even with aspm set to 0 in sysctl. Upgrading coreboot to 0.9.1-rc3 fixed all issues and the device is very stable now.

[dirtyfreebooter]

i stumbled across this bug discussing the i226 TX hang on FreeBSD: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279245

there is shell script, aspm_disable attached at the bottom, you can easily disable ASPM on PCI device at run-time / boot. seems to work no matter the BIOS settings for ASPM control. only tested on OPNsense DEC3920.

Code Select Expand

# pciconf -l | grep igc
igc0@pci0:1:0:0:        class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
igc1@pci0:2:0:0:        class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
igc2@pci0:3:0:0:        class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
igc3@pci0:4:0:0:        class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000

# aspm_disable 02:00.0
  PCIe capability found at offset 0xa0
  Link Control offset: 0xb0
  Current Link Control: 0x0042
  New Link Control (ASPM disabled): 0x0040
  setpci -s 02:00.0 b0.w=0040
  ASPM disabled for 02:00.0.

i copied the script to /usr/local/bin and then added a syshook script to execute early (before network) on boot:

Code Select Expand

# chmod 755 /usr/local/etc/rc.syshook.d/early/99-aspm-disable
# cat /usr/local/etc/rc.syshook.d/early/99-aspm-disable
#!/bin/sh
/usr/local/bin/aspm_disable 02:00.0 > /dev/null


[dirtyfreebooter]

Issue: Lots of RX errors / missed packets when the NIC is connected to Arris ONT Calix 711GE ONT, connecting it to switch or computer gives no error. Swapping igc0/igc1 makes no difference. So many pkts are missed that it will frequently look like DNS issues, due to missed SYN-ACKs and long delays to connect to websites.

interesting, i seemed to have not had any issues with a Protectli VP2440 connected to Calix 711GE ONT, but then i replaced it with an official Deciso DEC3920 and had tons of WAN issues. my issues tho, the WAN would go completely out and only physically removing and reinserting the cable would restore the connection. i seemingly got it stable, but only after so many tweaks back and forth, i don't 100% know the root cause, only the set the tunables that seems to be stable -> https://forum.opnsense.org/index.php?msg=264927

i upgraded the protectli from 2.17 to 2.32 firmware, i left the deciso at 2.25 *shurg*

edit: oh i c, i was also running 0.9.1-rc3 on VP2440.. yea 0.9.0 coreboot was 100% broken for FreeBSD + igc because of ASPM. AMI bios completely disabled ASPM, adds 4-5w to idle, which is like 50%, but also solves the issues.