Furcsán hibázó Intel hálókártya

Segítettem pár munkatársnak összeállítani néhány gépet, amikkel molekuláris dinamikai szimulációkat akartak futtatni. Végeztem előtte pár tesztet egy dupla Xeon E5530 CPU-t + 4 db GTX 980 GPU-t tartalmazó géppel, összefoglalva az jött ki, hogy mindig CPU-limites a számolás - mivel a hosszú hatótávú kölcsönhatásokat ott számolja a program - tehát egy erős CPU mellé elég egy jó GPU-t venni az optimális teljesítményhez. A következő konfigurációt állítottam össze, amivel még épp belefértek az elérhető keretösszegbe: Intel Skylake i7-6700, ASRock Z170 Pro4S alaplap, 16 GB DDR4, meg egy GTX 980 GPU. Remek, megrendeltük, megjött, összerakták, majd első körben egy Debian Jesse ment rá (ez volt a kérésük), ekkor kezdődtek a problémák...

Az alaprendszer viszonylag gond nélkül felment, de amikor a CUDA 7.5-öt akartuk volna felrakni, checksum error-t dobott a telepítő. Hmm... Áttöltjük SSH-n keresztül még egyszer, majd nézünk egy md5sum-ot, különbözik. Újra próbálkozva megint változott az md5 hash, illetve néha még kernel panic-kal le is fagyott az egész gép... Itt valami gond lesz a hálókártyával (Intel i219V), kerestünk hát friss drivert az Intel oldalán, azonban Debian 8 alatt nem tudtuk lefordítani. Ekkor véget is ért az első nap, mert más dolgunk akadt, gondoltam legközelebb megpróbálkozok egy Ubuntuval, az hátha megy.

Második nap, Ubuntu 14.04 server. Kolléga előzetesen megpróbálta felrakni a rendszert, de a telepítés közben leállt, kipróbálta 15.10-zel is, ugyanaz a jelenség. Amikor odajutottam, elölről kezdve nekiálltam én is egy telepítésnek. Akkor állt le a folyamat, amikor a hálózatról leszedte a frissített csomagokat. A hibakonzolon azt láttam, hogy szépen kivégezte önmagát a telepítő, mert random checksum hibás csomagokkal próbált frissíteni, ezáltal dependency hellt idézett elő... Újra próbálkozva, mindenféle hálózati forgalmat mellőzve felment a rendszer, de az első frissítésnél/csomagtelepítésnél ismét dep-hell-szerű állapot állt elő a hibásan leszedett csomagok miatt. Frissítve a hálókártya kernel modulját, többet nem is töltött be a rendszer. Itt megint elnapoltuk a dolgot, mert sajna nem volt egy PCIE hálókártyánk, amit bele tudtunk volna rakni a gépbe.

Harmadik napon végre több időm volt a problémával foglalkozni, meg szereztem egy USB-s WiFi adaptert, ami támogatott Linux alatt is. De gondoltam induljunk tiszta lappal, frissítettem először a BIOS-t, bocs EUFI-t. Ezután meglepő módon főnixmadárként született újjá hamvaiból az Intel hálókártya, egy Ubuntu 14.04 gond nélkül felment frissítésekkel együtt pár perc alatt. A teszt céllal átmásolt pár GB-nyi adat is hibátlanul megérkezett a gépre. A CUDA 7.5 is felment, az MD szimuláció meg "szélvész gyorsan" futott (egy 7k atomot tartalmazó rendszernél ~370 ns-nyi időléptetést számolt ki egy nap alatt). Öröm, bódottá.

Ok, persze lehetett volna egyből UEFI-frissítéssel kezdeni, megspórolva némi időt, azonban most találkoztam először ilyen hibával. Naivan azt gondoltam, hogy csak nem adják el olyan UEFI-vel az alaplapot, amivel hibásan működik a hálókártya. Találós kérdés: ha az UEFI saját, netes frissítőjét használom, akkor kivégzem vele az alaplapot, vagy ellenőriz azért egy checksum-ot mielőtt felülírja magát? :)

tl;dr: viszonylag új hardvernél tapasztalt megmagyarázhatatlan hibák esetén nem árt egy BIOS-frissítéssel kezdeni a napot.

Hozzászólások

En naivan azt gondolnam, hogy ellenorzi a checksumot, vegulis erre meg a DOS-os BIOS frissitok is kepesek voltak, csak implementaltak valami ilyesmit egy azoknal sokkal okosabb cuccba.
--
Blog | @hron84
Üzemeltető macik

Réges régen egy messzi...nah jó már a csapból is ez folyik...de igen. Régen amikor még gépösszerakásból/szervizelésből éltem, megszoktam hogy új gép összerakása után első sw-es dolgom gyártó weblapja, új bios keresése. Ezek szerint még az is lehet hogy megannyi év alatt ezzel a berögzült szokásommal pár kellemetlen helyzettől kíméltem meg magam! :)

A UEFI Driver Writers' Guide-ban kihangsúlyozzák, hogy hálókártya driver-ében (pl. a Simple Network Protocol implementációjában) az ExitBootServices() callback-ben (amikor a vezérlés lényegében átkerül a firmware-től ("boot time") az OS-hez ("runtime")), a hálózati kártyát -- a memóriafoglalási szolgáltatások használata nélkül -- újra kell inicializálni.

Újra kell inicializálni abban az értelemben, hogy a függőben levő átviteleket (DMA) meg kell szakítani -- ellenkező esetben a "boot time" alatt beindított / konfigurált rx a runtime OS memóriáját felülírhatja.

Ezt a hibát többször is láttam, gyakorlatban.

Persze elképzelhető, hogy a te esetedben a platform firmware simán "rosszul állította be" a hálókártyát.

... Ha jól értem, a kérdéses kártya integrált. Diszkrét PCIe kártyánál a kártyához való UEFI SNP driver rendszerint a kártya ROM BAR-jából jön (= a kártya saját expansion ROM-ja szolgáltatja a UEFI drivert). Diszkrét kártyánál az oprom-ban található drivert körülményesebb lehet frissíteni -- ill. helyettesítő meghajtóval felülbírálni --, viszont a kártyát legalább tokkal-vonóval ki lehet cserélni (akár más gyártóéra). Továbbá virtuális géphez integrált alaplapi eszközt hozzárendelni, általánosan beszélve, nem lehet, vagy nem biztonságos.

Találós kérdés: ha az UEFI saját, netes frissítőjét használom, akkor kivégzem vele az alaplapot, vagy ellenőriz azért egy checksum-ot mielőtt felülírja magát? :)

A fenti két esetből (1: hiányzó NIC reset az ExitBootServices() callback-ben, 2: szimplán rossz konfiguráció) az 1-esnél definíció szerint nem látod a hibát "boot time" alatt (mivel ExitBootServices() előtt a hiba nem is létezik). A 2-es (= "egyéb konfig") probléma pedig UEFI alatt vagy látható, vagy nem; a runtime OS hálózati stack sokkal intenzívebben hajt(hat)ja a kártyát, mint a boot time meghajtók és alkalmazások.

Én egy UCS szervernél találkoztam olyannal, hogy friss telepítés után nagyon lassú volt a megjelenítés. Szaggatva ment az egér.

Megoldás:
Hálókártya driver frissítés. :D