Sziasztok!
MEGOLDVA: Ha esteleg valaki ide téved ilyen problémával, AsrockRack végre kiadott FW csomagot direkt erre az alaplapra, amiben benne van a módosított FW.
https://www.asrockrack.com/support/faq.asp legalján >How to Update X550-AT2 on ROMED8-2T and X570D4u-2L2T.
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?
Sajnos nem, már azt is próbáltam.
HW support nekünk ilyen anomáliákkor mindig full áramtalanítást javasol. Ha az sem segít, akkor tényleg RMA.
Itt az sem segít, minden update után teljes áramtalanítás van.
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...
ez azért érdekes, mert szerver esetén simán lehet fw-t frissiteni, és reboot-kor (esetleg power-cycle után) kerül bele az online rom-ba az fw...
Í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.
Igen ez furcsa volt nekem is. Viszont ne a régit próbáld hanem a jelenlegit újra. Azt sem lehet?
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...
Sajnos nem megy, csak a port0 működik, port1-en továbbra sincs link.
Driver frissítés?
https://cdrdv2.intel.com/v1/dl/getContent/335253
NVM and Software Compatibility rész az érdekes
Köszi, ezt meglesem, mert érdekes kombók vannak itt. Délután majd megpróbálok eszerint firmware-t cserélni kihúzott kábelekkel.
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.
ipon.hu tavaly szeptember elején.
Á 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...
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.
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?
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.
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.
És csak az egyik portnak? A másik miért működik jól?
Más gyártónál is van ilyen, meg van adva melyik firmware-hez milyen OS-driver kell minimum.
Te esetedben is ez van, működik de szarúl, ezt is javíthatták* az újabb OS-driverben.
szavak végén ul-ül rövid :)
Fordítottam a Proxmox kernelhez (5.4.78-2-pve) a NVM 3.15 firmware-hez tartozó 5.9.4-es modult.
Port0
Port1
Tehát továbbra is ugyanaz történik.
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.
Szia!
Firmware frissítés után, megnézted a BIOS-ba miket lehet állítani? ( nincs valami letiltva?)
Teszt:
-Ha összekötöd 1db kábellel a két portot akkor van link?
- BIOS-ban ugyanazok vannak mint előtte, le lehet egyenként tiltani a portokat (ezt is próbáltam, ena/disa/reboot), meg PXE+UEFI boot van.
- Ha összekötöm a két portot akkor sincs link egyiken sem.
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.
Amiket Te nézel azok WS alaplapok (Threadripper Pro CPU-hoz) és van rajta chipset, ami nekem van az szerver alaplap, azokon általában nincs chipset, minden a CPU-ba van "bekötve".
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
UEFI shell-ből tudsz
paranccsal IP címet rendelni a kérdéses porthoz (DHCP-vel vagy statikusan), és utána megy a
?
https://github.com/tianocore/edk2/releases/download/edk2-stable202002/S…
http://www.uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf
Semmilyen OS alól nics link, UEFI alatt sem.