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

Hálózati eszközök
  • 580 megtekintés

( sibike | 2021. 01. 16., szo – 21:29 )

Ez szep, szereted a kihivasokat. :)

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

( slinky v | 2021. 01. 16., szo – 22:10 )

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.

( andrej_ v | 2021. 01. 17., v – 12:32 )

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...

( uid_2716 | 2021. 01. 17., v – 15:04 )

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.

( debtamas88 | 2021. 01. 17., v – 17:51 )

Szia!

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

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.



 

( arpi_esp v | 2021. 01. 18., h – 00:22 )

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