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

Started by BrandyWine, August 31, 2025, 05:21:07 PM

Previous topic - Next topic
Adding some more tidbit info.
Digging some more around ASPM and related reports that ASPM was causing issues with links dying.

Interestingly enough, i226 ASPM capability is L1 only (no L0s), and my x520 is L0s only (no L1), and my SSD is L0s/L1 capable.

226 LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L1
520 LnkCap: Port #0, Speed 5GT/s, Width x8, ASPM L0s
ssd LnkCap: Port #1, Speed 8GT/s, Width x4, ASPM L0s L1

So with ASPM enabled it's possible the i226 pci link went totally offline, but the x520 will never have that issue.
Mini-pc N150 i226-V

Guess what? I had exactly that link dying issue issue with an Intel 82599ES (which is the X520-DAx chipset) and it went away only after I set hw.pci.enable_aspm=0.
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

Quote from: meyergru on September 25, 2025, 08:45:01 AMGuess what? I had exactly that link dying issue issue with an Intel 82599ES (which is the X520-DAx chipset) and it went away only after I set hw.pci.enable_aspm=0.

That's odd. Maybe state L0s is an issue too. L0s only sleeps one half of pci link, but has fast recovery.

Maybe check your nic capabilities (lspci -vv) and see what your x520 has, maybe different NVM's have different bits set.

Mini-pc N150 i226-V

Nope:

# pciconf -lbcv ix1@pci0:1:0:1
ix1@pci0:1:0:1: class=0x020000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x000c
    vendor     = 'Intel Corporation'
    device     = '82599ES 10-Gigabit SFI/SFP+ Network Connection'
    class      = network
    subclass   = ethernet
    bar   [10] = type Memory, range 64, base 0x81080000, size 524288, enabled
    bar   [18] = type I/O Port, range 32, base 0x3000, size 32, enabled
    bar   [20] = type Memory, range 64, base 0x81200000, size 16384, enabled
    cap 01[40] = powerspec 3  supports D0 D3  current D0
    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
    cap 11[70] = MSI-X supports 64 messages, enabled
                 Table in map 0x20[0x0], PBA in map 0x20[0x2000]
    cap 10[a0] = PCI-Express 2 endpoint max data 256(512) FLR RO NS
                 max read 512
                 link x4(x8) speed 5.0(5.0) ASPM disabled(L0s)
    cap 03[e0] = VPD
    ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
    ecap 0003[140] = Serial 1 90e3baffff00be8a
    ecap 000e[150] = ARI 1
    ecap 0010[160] = SR-IOV 1 IOV disabled, Memory Space disabled, ARI disabled
                     0 VFs configured out of 64 supported
                     First VF RID Offset 0x0180, VF RID Stride 0x0002
                     VF Device ID 0x10ed
                     Page Sizes: 4096 (enabled), 8192, 65536, 262144, 1048576, 4194304
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

September 25, 2025, 06:26:05 PM #94 Last Edit: September 25, 2025, 06:56:52 PM by BrandyWine
cap 10[a0] = PCI-Express 2 endpoint max data 256(512) FLR RO NS
                 max read 512
                 link x4(x8) speed 5.0(5.0) ASPM disabled(L0s)
That's the lnk control settings as defined by bios/driver/app, etc. You disabled ASPM from (wherever) and it shows in [a0] area.
And (as we discussed earlier for what it means), the L0s in "ASPM disabled(L0s)" is telling us what specific L state is disabled. You could technically have L0s/L1 capability in nvm but have only disabled L0s, and it would show in config space as "ASPM disabled(L0s)"

I do however suspect your x520 only has L0s in NVM.
It doesn't make much sense that a nic link (pci link) would drop out in L0s, because there's plenty of wake-up routine to bring it back very fast. If the root issue is in L0s wake-up, then this to me says probably an issue in the driver code. Could probably add some debug code into driver src and recompile and load in as KLM, to see why L0s wake-up is not working as expected.



Grab lspci -vv -d 8086:10fb
Pciconf is giving condensed config space info with byte locations in []
These byte locations (for each device id) are seen from lspci -xxxx

LnkCap are bit settings for capable features coded into nvm.

Side note: my i226's have MAC from vendor Techno Scope Co. Ltd, not Intel. Hmmmm. Maybe BIOS doing it.


Mini-pc N150 i226-V

All I can say it did expose the typical "no more network" behaviour before I disabled ASPM via the tuneable about once per week and not anymore since.
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

September 30, 2025, 08:08:10 PM #96 Last Edit: September 30, 2025, 08:12:17 PM by nightcom
Thanks all of you for this topic!

I upgraded my Hunsn RJ03 with i226-V from 2.17 to 2.32 version (1MB), all 4 ports without issues.

To anyone with same device:
Vendor, device etc. is the same as in default config, all you need to do is change MAC address and reboot to take effect.

P.S. I don't know if it's placebo but it seems more responsive after upgrade

Quote from: nightcom on September 30, 2025, 08:08:10 PMThanks all of you for this topic!

P.S. I don't know if it's placebo but it seems more responsive after upgrade

Probably is more responsive. New nvm with a matching new driver.
There's text in some Intel notes that say "don't run this new driver w/o 1st getting latest device firmware", paraphrased, not specifically for i226.
Mini-pc N150 i226-V