Intel X550-T2 firmware update a ROMED8-2T alaplapon.

Sziasztok!

Pár hónapja vettem egy AsrockRack ROMED8-2T alaplapot amiben egy EPYC 7451 CPU van és Proxmox VE linuxot futattok rajta.

Az alaplapon egy dual Intel X550-T2 NIC van ami tud SR-IOV-t és nagyon jól jön a linux és a windows guesteken is, de LXC-t is szerettem volna használni, viszont ez sajnos nem ment együtt. Vagy SR-IOV vagy a linux bridge mód ment, az újabb firmware javítja a hibát.

Sajnos a firmware 2018-as és eléggé elavult.

A hozzáadott firmware: V1.93 80000AEE 2018-05-25
A legfrissebb firmware: V3.15 80001373 2020-11-10.

Ezért írtam az AsrockRack supportnak, akik nem értették hogy miért is akarok én firmware-t frissíteni, de aztán hosszas levelezés után abban maradtunk, hogy csináljam az Intel hivatalos oldal szerint és majd számoljak be róla. :)

Szóval letöltöttem a legfrissebb firmware pakkot az Intel oldaláról.
https://downloadcenter.intel.com/download/28336/Non-Volatile-Memory-NVM…

Az UEFI módot használtam, mert akkor biztos nem használja semmi a kártyát.

# nvmupdate64e -u -b -l -o update.xml -c nvmupdate.cfg
Intel(R) Ethernet NVM Update Tool
NVMUpdate version 1.35.42.7
Copyright (C) 2013 - 2020 Intel Corporation.

Config file read.
Inventory
[00:098:00:00]: Intel(R) Ethernet Controller X550-T2
        Flash inventory started.
        Shadow RAM inventory started.
        Shadow RAM inventory finished.
        Flash inventory finished.
        OROM inventory started.
        OROM inventory finished.
[00:098:00:01]: Intel(R) Ethernet Controller X550-T2
        Device already inventoried.
Update
[00:098:00:00]: Intel(R) Ethernet Controller X550-T2
        Creating backup images in directory: D05099DB878F.
        Backup images created.
        Flash update started.
|======================[100%]======================|
        NVM verification started.
        Shadow RAM verification started.
|======================[100%]======================|
        Shadow RAM verification finished.
        Flash verification started.
|======================[100%]======================|
        Flash verification finished.
        NVM verification finished.
        Flash update successful.
Update security revisions
[00:098:00:00]: Intel(R) Ethernet Controller X550-T2
        Skipping update minimum security revisions.
Checking update availability for next tool run.
Post update inventory
[00:098:00:00]: Intel(R) Ethernet Controller X550-T2
        Flash inventory started.
        Flash inventory finished.
        OROM inventory started.
        OROM inventory finished.
[00:098:00:01]: Intel(R) Ethernet Controller X550-T2
        Device already inventoried.
Power Cycle is required to complete the update process.

The update.xml tartalma:

<?xml version="1.0" encoding="UTF-8"?>
<DeviceUpdate lang="en">
    <Instance vendor="8086" device="1563" subdevice="1563" subvendor="1849" bus="98" dev="0" func="0" PBA="000000-000" port_id="Port 1 of 2" display="Intel(R) Ethernet Controller X550-T2">
        <Module type="PXE" version="2.4.44" previous_version="2.4.32" display="">
            <Status result="Success" id="0">All operations completed successfully.</Status>
        </Module>
        <Module type="EFI" version="7.8.13" previous_version="7.0.19" display="">
            <Status result="Success" id="0">All operations completed successfully.</Status>
        </Module>
        <Module type="NVM" version="80001373" previous_version="80000AEE" display="">
            <Status result="Success" id="0">All operations completed successfully.</Status>
        </Module>
        <VPD>
            <VPDField type="String">Intel (r) Ethernet Controller X550</VPDField>
        </VPD>
        <MACAddresses>
            <MAC address="D05099DB878F">
            </MAC>
            <AltMAC address="D05099DB878F">
            </AltMAC>
        </MACAddresses>
    </Instance>
    <Instance vendor="8086" device="1563" subdevice="1563" subvendor="1849" bus="98" dev="0" func="1" PBA="000000-000" port_id="Port 2 of 2" display="Intel(R) Ethernet Controller X550-T2">
        <Module type="PXE" version="2.4.44" previous_version="2.4.32" display="">
            <Status result="Success" id="0">All operations completed successfully.</Status>
        </Module>
        <Module type="EFI" version="7.8.13" previous_version="7.0.19" display="">
            <Status result="Success" id="0">All operations completed successfully.</Status>
        </Module>
        <Module type="NVM" version="80001373" previous_version="80000AEE" display="">
            <Status result="Success" id="0">All operations completed successfully.</Status>
        </Module>
        <VPD>
            <VPDField type="String">Intel (r) Ethernet Controller X550</VPDField>
        </VPD>
        <MACAddresses>
            <MAC address="D05099DB8790">
            </MAC>
            <AltMAC address="D05099DB8790">
            </AltMAC>
        </MACAddresses>
    </Instance>
    <NextUpdateAvailable> 0 </NextUpdateAvailable>
    <RebootRequired> 0 </RebootRequired>
    <PowerCycleRequired> 1 </PowerCycleRequired>
</DeviceUpdate>

A power cycle megvolt indul a Proxmox. A két NIC látszik linux alatt betölti rendesen a kernel modulet is.

# ethtool -i enp98s0f0
driver: ixgbe
version: 5.1.0-k
firmware-version: 0x80001373, 1.2203.0
expansion-rom-version:
bus-info: 0000:62:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

# ethtool -i enp98s0f1
driver: ixgbe
version: 5.1.0-k
firmware-version: 0x80001373, 1.2203.0
expansion-rom-version:
bus-info: 0000:62:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

Na minden ok, csak hogy a port1-en nincs link, a port0 teljesen jól működik.
Mondanom sem kell,hogy frissítés előtt mindekettő jó volt.

Most azonban csak a port0 jó, port1 no link:

# ethtool enp98s0f0
Settings for enp98s0f0:
    Supported ports: [ TP ]
    Supported link modes:   100baseT/Full
                            1000baseT/Full
                            10000baseT/Full
    Supported pause frame use: Symmetric
    Supports auto-negotiation: Yes
    Supported FEC modes: Not reported
    Advertised link modes:  100baseT/Full
                            1000baseT/Full
                            10000baseT/Full
    Advertised pause frame use: Symmetric
    Advertised auto-negotiation: Yes
    Advertised FEC modes: Not reported
    Speed: 10000Mb/s
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: on
    MDI-X: Unknown
    Supports Wake-on: umbg
    Wake-on: g
    Current message level: 0x00000007 (7)
                   drv probe link
    Link detected: yes

# ethtool enp98s0f1
Settings for enp98s0f1:
    Supported ports: [ TP ]
    Supported link modes:   100baseT/Full
                            1000baseT/Full
                            10000baseT/Full
    Supported pause frame use: Symmetric
    Supports auto-negotiation: Yes
    Supported FEC modes: Not reported
    Advertised link modes:  100baseT/Full
                            1000baseT/Full
                            10000baseT/Full
    Advertised pause frame use: Symmetric
    Advertised auto-negotiation: Yes
    Advertised FEC modes: Not reported
    Speed: Unknown!
    Duplex: Unknown! (255)
    Port: Twisted Pair
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: on
    MDI-X: Unknown
    Supports Wake-on: umbg
    Wake-on: g
    Current message level: 0x00000007 (7)
                   drv probe link
    Link detected: no

Ellenőriztem a firmware-t:

# nvmcheck64e /DEVICES
Intel(R) NVM Integrity Verification Tool
Nvmcheck version 1.35.57.00
QV SDK version 2.35.57.00
Copyright(C) 2012 - 2020 Intel Corporation.

NIC B/D/F     Ven-Dev   MAC          ENA Branding string
=== ========= ========= ============ === ======================================
 1) 098/00/00 8086-1563 D05099DB878F YES Intel(R) Ethernet Controller X550-T2
 2) 098/00/01 8086-1563 D05099DB8790 YES Intel(R) Ethernet Controller X550-T2

# nvmcheck64e /NIC=1 /VERIFY
Intel(R) NVM Integrity Verification Tool
Nvmcheck version 1.35.57.00
QV SDK version 2.35.57.00
Copyright(C) 2012 - 2020 Intel Corporation.

NVM module: Option ROM.
NVM Integrity verification PASSED.

NVM module: PHY Firmware.
NVM Integrity verification PASSED.

NVM module: EMP image.
NVM Integrity verification PASSED.

# nvmcheck64e /NIC=2 /VERIFY
Intel(R) NVM Integrity Verification Tool
Nvmcheck version 1.35.57.00
QV SDK version 2.35.57.00
Copyright(C) 2012 - 2020 Intel Corporation.

NVM module: Option ROM.
NVM Integrity verification PASSED.

NVM module: PHY Firmware.
NVM Integrity verification PASSED.

NVM module: EMP image.
NVM Integrity verification PASSED.

Szóval látszólag minden ok, csak éppen link nincs.
Az intel diagtool teszt vévig megy, csak a link teszten nem.
A készített backup firmware-t meg nem lehet visszatölteni, mert "Rollback blocked" hibát dob az nvmupdate.

AsrockRack még nem válaszolt, illetve küldtek word doksiba ágyazott zip fájlt, amiben a régi eeprom-os tool volt, hogy majd azzal írjam vissza a MAC addresst, ami persze nem működik (és nincs is gond a MAC addressel), mert ezek az új kártyák már NVM flasht használnak.
Próbáltam több külföldi fórumon is segítséget kérni, de mindenhol csak RMA-t javasolnak.

Már több mint 1 hónapja megy a levelezés az AsrockRack support-al, azóta már számtalan más firmware verziót is kipróbáltam és mindegyiknek az a vége, hogy a port0 jó, a port1 viszont no link.

Kinek van ötlete? 

Hozzászólások

Ez szep, szereted a kihivasokat. :)

Manualisan sem tudod felhozni a linket, kezzel beallitva a sebesseget?

volt egy olyan X550 FW bug, hogy ha link up volt SFP+ -on upgrade kozben akkor szopo volt.

Ez jól hangzik :(

Azért is csináltam UEFI alatt, hogy ne használja semmi közben, mondjuk a switch-ből nem húztam ki, de azt semmi sem írta, hogy ezt így kell. Meg különben is.

Na meg, hogy lehet hogy a port0 jó lett, de a port1 no link?

Most megy az SR-IOV meg a bridge is. De egyébként ez copper nem SFP.

Ugyanazt a Firmware-t vissza tudod tenni? Mert egy próbát megérne úgy, hogy kihúzod a kábelt. Ha az be van dugva, akkor ott van link és akkor olyan nincs, hogy "nem használja semmi". Egyébként pedig sok alaplap (nekem is van egy Asrock, ami pont ilyen) UEFI setup alól képes már online frissítésre, szóval UEFI módban is simán lehet, hogy a kártya be van töltve a mikrokernelbe. De nem is ez a lényeg, hanem a link. Ha a másik végén működő eszköz van, akkor ott van forgalom. Mennek a keretek, mennek a csomagok ugyanúgy. Az más kérdés, hogy a kártya elméletileg mindet eldobja de ha kapna mondjuk egy magic packetet akkor lehet, hogy reagálna. Intelligensebb kártyák simán megújítják a lejáró IP-jüket a DHCP felé kikapcsolt állapotban is. Szóval húzd ki a kábelt és tedd fel újra a FW-t ha lehet. Hátha bejön :)

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Így van, a szervereknél a firmware csak power cycle után érvényesül. Egyébként meg írtam a cikkben is, hogy a régit nem tudom visszatenni, mert "Rollback blocked." Az is érdekes, hogy egy firmware update felismeri az eszközt, hogy frissíthető, hagyja hogy csináljak backup-ot a régiről, aztán amikor visszakaarom tölteni akkor közli, hogy ez nem fog mennni.

A táblázat szerint az alaplap eredeti 1.93-as NVM verziója a holtpont, ahonnan ha firmware update van a rollback már nem lehetséges. Mondjuk ezt az update-nél kiírhatta volna, de semmi ilyet nem csinált.

Szóval megpróbáltam megint a legújabb NVM 3.15-ös verziót feltenni kihúzott kábelekkel, de az eredményen nem változtatott, port0 működik, port1-en nincs link.

Egyébként a uplinkhez szerintem nem kell betöltött OS driver, mert eddig is amint elindítottam a gépet pár másodpercre rá feljött a link mindkét porton (már amikor még jó volt a régi firmware alatt).  pedig még csak a POST futott, ami kb. 1 perc mire eljut az OS bootig.

Ami még érdekes, hogy a Proxmox jelenlegi ixgbe modul verziója 5.1.0-k, a jelenlegi 3.15-ös firmware-hez meg az 5.9.4 kellene, mégis megy vele minden a port0-án.

Majd még megpróbálok hozzá fordítani új drivert, csak ahhoz fel kell tennem a dev csomagokat, bár nem sok esélyt látok rá, hogy feléledjen.

Hol vetted a lapot? Engem a Ryzen-es változat érdekelne, nemkicsit, nagyon... :) X570Dakármi.

Á télleg köszi. Ami viszont bánt, hogy AM4-es 1U-s normális (100W...) borda nincs, illetve hogy az X570-es lapon a venti kivezetések nem túl nyerőek egy Supermicro házikóhoz. Pedig egy 10SFF házikóval, egy jó HBA-val elég dulva kombó lenne összehozható. Olcsó nem lenne egy 5900X-szel, meg 128G memóval, de hát valamit valamiért.

Még a Supermicro új Threadripper Pro-s lapját néztem, ahhoz is vmi 1U-s szörnyeteg 10SFF-fel...

Rollback blocked

Hát ezért nem hiszek én a firmware frissítésben, az automatikusban meg egyáltalán nem. Esetleges regresszió -> kuka az eszköz; még ha az RMA (?) lehetséges is, akkor is kiesés, nyűglődés. Ha nem jó a firmware, akkor nem jó az eszköz; rendes üzembe vétel előtt csere tokkal-vonóval, vagy ha megy, akkor végig az a firmware marad rajta.

Nem véletlen, hogy a kernel csomag "installonly" -- ha problémás a legfrissebb, simán indítod az eggyel korábbit a grub menüből. Minél alacsonyabb szinten fut egy komponens, annál fontosabb (lenne) ez.

Még ha RMA lenne, akkor is visszakapnék egy olyan terméket ami elavult firmware-t tartalmaz és így számomra nem használható.

Sajnos az alaplap manualban egy szó sincs arról, hogy a benne lévő 3rd party eszközök milyen firmware-t tartalmaznak. Így ez a legtöbb esetben lutri, ami nem is lenne annyira gond, ha a gyártó biztosítaná a megfelelő firmware update csomagokat. De nincs még a support sem tud segíteni, csak azt hajtogatja, hogy RMA. Valahogy csak rátette valaki/mi azt az eredeti firmware-t, miért nem lehet adni rá egy csomagot, ami visszarakja olyanra mint ami volt?

Végigpróbáltam 2.0-tól az összes verziót, megnéztem más gyártók (lenovo,dell,hp) is ugyanezeket az Intel gyári firmware-ket adják ki. Fogalmam sincs mit lehet elk*rni egy ilyen firmware update-nél? Hogy látszólag működik a kártya csak link nincs rajta.

Hát ezért nem hiszek én a firmware frissítésben

Ez nem hit kérdése. A hibákat javítani kell. Ha olyan gond van egy adott firmware-rel, amit egy újabb verzióban javítottak, akkor nem teszed fel az újabbat, mert nem hiszel benne, és élsz tovább a régi fw által okozott hibával?

A hibákat javítani kell

Zárt forrású / proprietary, visszavonhatatlan frissítésű, alacsony szintű komponenseknél -- amelyek alá nem tudsz más eszközzel benyúlni -- ez legjobb esetben is úgy hangzik, hogy a hibákat lehet perturbálni. Néhány ismert hibát elcserélsz néhány ismeretlen hibáért. Az ismert hibák gyakorlati jelentőségét ki tudod értékelni, az adott környezetben. A régi fw által okozott hiba sok esetben egyáltalán nem jelentkezik a gyakorlatban (vagy relatíve kicsi fennakadást okoz), az új verzió regressziója viszont katasztrofális lehet.

A jelen esetben is pontosan ez történt; OP az ismert hibát -- ha jól értem: a VF-ek nem használhatók egy időben a PF bridge-elésével -- felcserélte egy ismeretlen hibára (csak az egyik port működik). Most, ha tudna, visszaállna az előző állapotra. De (úgy látszik) nem tud.

(Hasonló okból nem telepítek CPU mikrokódot firmware szinten, hanem csak microcode_ctl csomagban. Ha az utóbbi sokat késve követi az előbbit, akkor a firmware update-ből kibányászom a mikrokódot, és kézzel betöltöm az OS alól.)

Tehát a mondandómat pontosítandó, nem a fw hibák javításában nem hiszek, hanem a javítások jelenlegi terjesztési/telepítési módszerében. Az utóbbiak simán tudnak nagyobb bajt (regressziót) okozni a termelékenységben, mint az eredeti fw hibák. (Ld. még a frissítések "mindent vagy semmit" természetét.)

Ha van alkalom "eldobható", de egyébként azonos platformon kitesztelni az új fw verziót, az persze más.

Operációs rendszer (minor release) frissítések után is majdnem mindig fogok regressziót, de ott legalább van lehetőség  "yum downgrade"-et futtatni, a tünetet egy problémás (forrás)csomagra szűkíteni, hibát bejelenteni, a forráskódba magamnak belenézni.

... ~9 éve firmware fejlesztőként dolgozom (szerk.: elsősorban); nézd el nekem, hogy a tágabb fw fejlesztői közösségben látott kód ill. viselkedés alapján nem bízom vakon a frissítésekben :)

Nem lenne persze semmi baj, ha vagy a visszavonhatóság, vagy az "alányúlás lehetősége más eszközzel" elsődleges szempont lenne firmware telepítésnél.

"Ami működik, azt nem kell megjavítani."

"A jónál nem kell jobb."

stb.

O.K., de itt nem ez volt a helyzet, volt egy zavaró probléma, amit orvosolni kellett.

 

Néhány ismert hibát elcserélsz néhány ismeretlen hibáért.

Van ilyen is, nyilván, de nem feltétlenül. Azért, mert időnként ez előfordul, nem kell általánosítani. Én sem szoktam naponta nézegetni, hogy jött-e ki új fw az alaplapomhoz, de akkor, ha valami probléma lenne vele, már figyelnék erre, és frissítenék, ha az új fw azt ígérné, hogy megoldja a problémámat.

Szia!

Szerintem csak az újabb intel-kernel-driver kell neki, utána menni fog.

Fordítottam a Proxmox kernelhez (5.4.78-2-pve) a NVM 3.15 firmware-hez tartozó 5.9.4-es modult.

# dmesg -T | grep ixgbe
[Sun Jan 17 20:14:29 2021] ixgbe: loading out-of-tree module taints kernel.
[Sun Jan 17 20:14:29 2021] ixgbe: loading out-of-tree module taints kernel.
[Sun Jan 17 20:14:29 2021] ixgbe 0000:62:00.0 0000:62:00.0 (uninitialized): ixgbe_check_options: FCoE Offload feature enabled
[Sun Jan 17 20:14:30 2021] ixgbe 0000:62:00.0: Multiqueue Enabled: Rx Queue count = 24, Tx Queue count = 24 XDP Queue count = 0
[Sun Jan 17 20:14:30 2021] ixgbe 0000:62:00.0: 31.504 Gb/s available PCIe bandwidth (8 GT/s x4 link)
[Sun Jan 17 20:14:30 2021] ixgbe 0000:62:00.0 eth0: MAC: 4, PHY: 3, PBA No: 000000-000
[Sun Jan 17 20:14:30 2021] ixgbe 0000:62:00.0: d0:50:99:db:87:8f
[Sun Jan 17 20:14:30 2021] ixgbe 0000:62:00.0 eth0: Enabled Features: RxQ: 24 TxQ: 24 FdirHash vxlan_rx
[Sun Jan 17 20:14:30 2021] ixgbe 0000:62:00.0 eth0: Intel(R) 10 Gigabit Network Connection
[Sun Jan 17 20:14:30 2021] ixgbe 0000:62:00.1 0000:62:00.1 (uninitialized): ixgbe_check_options: FCoE Offload feature enabled
[Sun Jan 17 20:14:30 2021] ixgbe 0000:62:00.1: Multiqueue Enabled: Rx Queue count = 24, Tx Queue count = 24 XDP Queue count = 0
[Sun Jan 17 20:14:30 2021] ixgbe 0000:62:00.1: 31.504 Gb/s available PCIe bandwidth (8 GT/s x4 link)
[Sun Jan 17 20:14:30 2021] ixgbe 0000:62:00.1 eth1: MAC: 4, PHY: 3, PBA No: 000000-000
[Sun Jan 17 20:14:30 2021] ixgbe 0000:62:00.1: d0:50:99:db:87:90
[Sun Jan 17 20:14:30 2021] ixgbe 0000:62:00.1 eth1: Enabled Features: RxQ: 24 TxQ: 24 FdirHash vxlan_rx
[Sun Jan 17 20:14:30 2021] ixgbe 0000:62:00.1 eth1: Intel(R) 10 Gigabit Network Connection
[Sun Jan 17 20:14:30 2021] ixgbe 0000:62:00.0 enp98s0f0: renamed from eth0
[Sun Jan 17 20:14:31 2021] ixgbe 0000:62:00.1 enp98s0f1: renamed from eth1
[Sun Jan 17 20:14:43 2021] ixgbe 0000:62:00.0: registered PHC device on enp98s0f0
[Sun Jan 17 20:14:43 2021] ixgbe 0000:62:00.1: registered PHC device on enp98s0f1
[Sun Jan 17 20:14:48 2021] ixgbe 0000:62:00.0 enp98s0f0: NIC Link is Up 10 Gbps, Flow Control: None

Port0

# ethtool -i enp98s0f0
driver: ixgbe
version: 5.9.4
firmware-version: 0x80001373, 1.2877.0
expansion-rom-version:
bus-info: 0000:62:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

# ethtool enp98s0f0
Settings for enp98s0f0:
        Supported ports: [ TP ]
        Supported link modes:   100baseT/Full
                                1000baseT/Full
                                10000baseT/Full
                                2500baseT/Full
                                5000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  100baseT/Full
                                1000baseT/Full
                                10000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 10000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: umbg
        Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

Port1

# ethtool -i enp98s0f1
driver: ixgbe
version: 5.9.4
firmware-version: 0x80001373, 1.2877.0
expansion-rom-version:
bus-info: 0000:62:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

# ethtool enp98s0f1
Settings for enp98s0f1:
        Supported ports: [ TP ]
        Supported link modes:   100baseT/Full
                                1000baseT/Full
                                10000baseT/Full
                                2500baseT/Full
                                5000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  100baseT/Full
                                1000baseT/Full
                                10000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: umbg
        Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: no

Tehát továbbra is ugyanaz történik.

# modinfo ixgbe
filename:       /lib/modules/5.4.78-2-pve/updates/drivers/net/ethernet/intel/ixgbe/ixgbe.ko
version:        5.9.4
license:        GPL
description:    Intel(R) 10GbE PCI Express Linux Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     AA8061C6A752528BD6CFE19
alias:          pci:v00008086d000015E5sv*sd*bc*sc*i*
alias:          pci:v00008086d000015E4sv*sd*bc*sc*i*
alias:          pci:v00008086d000015CEsv*sd*bc*sc*i*
alias:          pci:v00008086d000015CCsv*sd*bc*sc*i*
alias:          pci:v00008086d000015CAsv*sd*bc*sc*i*
alias:          pci:v00008086d000015C8sv*sd*bc*sc*i*
alias:          pci:v00008086d000015C7sv*sd*bc*sc*i*
alias:          pci:v00008086d000015C6sv*sd*bc*sc*i*
alias:          pci:v00008086d000015C4sv*sd*bc*sc*i*
alias:          pci:v00008086d000015C3sv*sd*bc*sc*i*
alias:          pci:v00008086d000015C2sv*sd*bc*sc*i*
alias:          pci:v00008086d000015AEsv*sd*bc*sc*i*
alias:          pci:v00008086d000015ADsv*sd*bc*sc*i*
alias:          pci:v00008086d000015ACsv*sd*bc*sc*i*
alias:          pci:v00008086d000015ABsv*sd*bc*sc*i*
alias:          pci:v00008086d000015B0sv*sd*bc*sc*i*
alias:          pci:v00008086d000015AAsv*sd*bc*sc*i*
alias:          pci:v00008086d000015D1sv*sd*bc*sc*i*
alias:          pci:v00008086d00001563sv*sd*bc*sc*i*
alias:          pci:v00008086d00001560sv*sd*bc*sc*i*
alias:          pci:v00008086d00001558sv*sd*bc*sc*i*
alias:          pci:v00008086d0000154Asv*sd*bc*sc*i*
alias:          pci:v00008086d00001557sv*sd*bc*sc*i*
alias:          pci:v00008086d0000154Dsv*sd*bc*sc*i*
alias:          pci:v00008086d00001528sv*sd*bc*sc*i*
alias:          pci:v00008086d000010F8sv*sd*bc*sc*i*
alias:          pci:v00008086d0000151Csv*sd*bc*sc*i*
alias:          pci:v00008086d00001529sv*sd*bc*sc*i*
alias:          pci:v00008086d0000152Asv*sd*bc*sc*i*
alias:          pci:v00008086d000010F9sv*sd*bc*sc*i*
alias:          pci:v00008086d00001514sv*sd*bc*sc*i*
alias:          pci:v00008086d00001507sv*sd*bc*sc*i*
alias:          pci:v00008086d000010FBsv*sd*bc*sc*i*
alias:          pci:v00008086d00001517sv*sd*bc*sc*i*
alias:          pci:v00008086d000010FCsv*sd*bc*sc*i*
alias:          pci:v00008086d000010F7sv*sd*bc*sc*i*
alias:          pci:v00008086d00001508sv*sd*bc*sc*i*
alias:          pci:v00008086d000010DBsv*sd*bc*sc*i*
alias:          pci:v00008086d000010F4sv*sd*bc*sc*i*
alias:          pci:v00008086d000010E1sv*sd*bc*sc*i*
alias:          pci:v00008086d000010F1sv*sd*bc*sc*i*
alias:          pci:v00008086d000010ECsv*sd*bc*sc*i*
alias:          pci:v00008086d000010DDsv*sd*bc*sc*i*
alias:          pci:v00008086d0000150Bsv*sd*bc*sc*i*
alias:          pci:v00008086d000010C8sv*sd*bc*sc*i*
alias:          pci:v00008086d000010C7sv*sd*bc*sc*i*
alias:          pci:v00008086d000010C6sv*sd*bc*sc*i*
alias:          pci:v00008086d000010B6sv*sd*bc*sc*i*
depends:        dca
retpoline:      Y
name:           ixgbe
vermagic:       5.4.78-2-pve SMP mod_unload modversions
parm:           IntMode:Change Interrupt Mode (0=Legacy, 1=MSI, 2=MSI-X), default 2 (array of int)
parm:           InterruptType:Change Interrupt Mode (0=Legacy, 1=MSI, 2=MSI-X), default IntMode (deprecated) (array of int)
parm:           MQ:Disable or enable Multiple Queues, default 1 (array of int)
parm:           DCA:Disable or enable Direct Cache Access, 0=disabled, 1=descriptor only, 2=descriptor and data (array of int)
parm:           RSS:Number of Receive-Side Scaling Descriptor Queues, default 0=number of cpus (array of int)
parm:           VMDQ:Number of Virtual Machine Device Queues: 0/1 = disable (1 queue) 2-16 enable (default=8) (array of int)
parm:           max_vfs:Number of Virtual Functions: 0 = disable (default), 1-63 = enable this many VFs (array of int)
parm:           VEPA:VEPA Bridge Mode: 0 = VEB (default), 1 = VEPA (array of int)
parm:           InterruptThrottleRate:Maximum interrupts per second, per vector, (0,1,956-488281), default 1 (array of int)
parm:           LLIPort:Low Latency Interrupt TCP Port (0-65535) (array of int)
parm:           LLIPush:Low Latency Interrupt on TCP Push flag (0,1) (array of int)
parm:           LLISize:Low Latency Interrupt on Packet Size (0-1500) (array of int)
parm:           LLIEType:Low Latency Interrupt Ethernet Protocol Type (array of int)
parm:           LLIVLANP:Low Latency Interrupt on VLAN priority threshold (array of int)
parm:           FdirPballoc:Flow Director packet buffer allocation level:
                        1 = 8k hash filters or 2k perfect filters
                        2 = 16k hash filters or 4k perfect filters
                        3 = 32k hash filters or 8k perfect filters (array of int)
parm:           AtrSampleRate:Software ATR Tx packet sample rate (array of int)
parm:           FCoE:Disable or enable FCoE Offload, default 1 (array of int)
parm:           MDD:Malicious Driver Detection: (0,1), default 1 = on (array of int)
parm:           LRO:Large Receive Offload (0,1), default 0 = off (array of int)
parm:           allow_unsupported_sfp:Allow unsupported and untested SFP+ modules on 82599 based adapters, default 0 = Disable (array of int)
parm:           dmac_watchdog:DMA coalescing watchdog in microseconds (0,41-10000), default 0 = off (array of int)
parm:           vxlan_rx:VXLAN receive checksum offload (0,1), default 1 = Enable (array of int)

Ezt szerintem eljátszhatnám visszafelé az összes eddig megjelent firmware-el és ugyan ez lenne az eredmény. Valamit mókolhattak az eredeti firmware-hez képest a cégnél, csak ez úgy látszik hétpecsétes titok.

Hát akkor ez nem nyert.

Alaplap kinézete alapján ez valamilyen "referencia" megoldás lehet ( AMD adott egy kész tervrajzot - alaplapgyártó megépítette ), "hasonló" alaplapok ugyanilyan LAN-chippel:
-ASUS WRX80 Pro
-GIGABYTE WRX80 SU8

(Fenti alaplapok LAN firmware-ét végső megoldásként megpróbálhatod felrakni rá - de még nem jelentek meg ezek az alaplapok)

Asrock manual is érdekes, "chipset: N/A" - tehát ez akkor WRX80 lenne? - kitudja.

 

az intel ugye csak a chipet gyartja, a hozza illesztett phy az barmi lehet, meg annak a bekotese (vezerlo busz) is. nyilvan itt van az eb elhaltolva, hogy a 2. port phy-jet nem oda kotottek ahova az intel referencia kartyajan szoktak, ezert nem talalja meg a driver. vszinu a driverben at kene egy szamot (busz cimezes/gpio lab) irni valahol es jo lenne... az alaplapi realtek chipekkel is ez volt sokaig (talan meg ma is?), hogy tobb fele keppen lehetett bekotni, es az alaplap gyartok szabadon varialtak, persze annak megfelelo drivert adtak hozza. linuxon meg lehetett debuggolni hogy epp melyik gpio labra mi van kotve... jobb esetbe csak a led-ek nem mukodtek :)

szerintem irj a kernel driver fejlesztonek/karbantartonak, hatha van otlete. nekem anno (mondjuk ez jo 20 eve volt) remote debuggolt ki egy hasonlo hibat egy 4 portos kartyanal a fejleszto :)

addig is ha nagyon kell a +1 port akkor vegyel egy intel kartyat, azzal menni fog az intel fw :)

A'rpi