Regression #12904


Intel X500 series interfaces (ixgbe) show incoming errors in 2.6/22.01, whereas they did not in 2.5.2

Added by Chris W 4 months ago. Updated 4 months ago.

Not a Bug
Hardware / Drivers
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


Notes as of the time of filing:
- Errors are only on incoming packets, not outgoing.
- All users reporting so far are using a switch upstream of their pfSense WAN.
- Users report there don't seem to be any problems with link negotiation.
- As would be expected, the error count returns to zero after a reboot.
- Reportedly is present both after a fresh install of 2.6, and after upgrading to 2.6 from 2.5.2, and then persists after converting to 22.01.

Users report that the following seem to have no effect on the issue:
- Disable flow control
- Disable hardware checksum offloading
- Swapping out CAT wire for new and/or known working

Only a handful of cases so far. Most error numbers are small and not concerning overall, but we may see more of this as 2.6/22.01 become more prevalent.

Actions #1

Updated by Jim Pingle 4 months ago

On the thread the person reporting it says the value of dev.ix.0.mac_stats.checksum_errs correlates to the very low number of errors they see. It's entirely possible these are real and were not properly reported on the previous version of the driver (which is now based on iflib). Given that the number is so low and not rapidly increasing, I'm not sure there is anything actionable here.

I'm not seeing any errors on any of my own X553 ix interfaces (6100, 7100).

Actions #2

Updated by Steve Wheeler 4 months ago

I'm unable to replicate this using an x520 NIC in an XG-7100:

[22.01-RELEASE][root@7100.stevew.lan]/root: netstat -i
Name    Mtu Network       Address              Ipkts Ierrs Idrop    Opkts Oerrs  Coll
ix0    1500 <Link#1>      8c:dc:d4:a8:15:e8 259154487     0     0 259272608     0     0
ix1    1500 <Link#2>      8c:dc:d4:a8:15:e8 240144841     0     0 240127722     0     0

[22.01-RELEASE][root@7100.stevew.lan]/root: sysctl -a | grep checksum_errs
dev.ix.5.mac_stats.checksum_errs: 0
dev.ix.4.mac_stats.checksum_errs: 0
dev.ix.3.mac_stats.checksum_errs: 0
dev.ix.2.mac_stats.checksum_errs: 0
dev.ix.1.mac_stats.checksum_errs: 0
dev.ix.0.mac_stats.checksum_errs: 0

Where ix0/1 are the expansion card:

dev.ix.0.%parent: pci2
dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x103c subdevice=0x17d3 class=0x020000
dev.ix.0.%location: slot=0 function=0 dbsf=pci0:2:0:0
dev.ix.0.%driver: ix
dev.ix.0.%desc: Intel(R) X520 82599ES (SFI/SFP+)

Actions #3

Updated by Steve Wheeler 4 months ago

That was in a lagg of ix0+1 but as a single interface it's no different:

[22.01-RELEASE][root@7100.stevew.lan]/root: netstat -i
Name    Mtu Network       Address              Ipkts Ierrs Idrop    Opkts Oerrs  Coll
ix0    1500 <Link#1>      8c:dc:d4:a8:15:e8 528355121     0     0 528355088     0     0
ix0       - fe80::%ix0/64 fe80::8edc:d4ff:f        0     -     -        6     -     -
ix0       -     528353533     -     - 528353693     -     -

That's connected via 10G DAC:

[22.01-RELEASE][root@7100.stevew.lan]/root: ifconfig -vvm ix0
ix0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: WAN
        ether 8c:dc:d4:a8:15:e8
        inet6 fe80::8edc:d4ff:fea8:15e8%ix0 prefixlen 64 scopeid 0x1
        inet netmask 0xffffff00 broadcast
        media: Ethernet autoselect (10Gbase-Twinax <full-duplex,rxpause,txpause>)
        status: active
        supported media:
                media autoselect
                media 10Gbase-Twinax
        plugged: SFP/SFP+/SFP28 1X Copper Active (Copper pigtail)
        vendor: BROCADE PN: 58-1000026-01 SN: CAX112240004092 DATE: 2012-06-16

Actions #4

Updated by Steve Wheeler 4 months ago

This looks almost certainly because of a driver change in 22.01/2.6:

The input error counter now displays the sum or a far larger number of error types and did not before. Including checksum errors.

Those errors would have existed in 21.05/2.5.2 but simply weren't shown.

Actions #5

Updated by Jim Pingle 4 months ago

  • Status changed from New to Not a Bug

That's what I expected given the behavior. It's just more accurate than it was in the past, so there isn't a bug here. Closing this out as there is nothing actionable.


Also available in: Atom PDF