Microcode SW error detected. Restarting 0x2000000. Vérnyomásom van tőletek.

 ( Gyuszk | 2018. április 12., csütörtök - 7:49 )

Hivatkozzuk be ezt a posztot nyugodtan amikor véresszemű Pistikék előjönnek azzal, hogy a Linux és az open source hibátlan.
Nem az. Bár az aktívan fejlesztett és használt disztrók, a kernel, és appok elég jók, azért itt is bőven becsúszik hiba. A stable ágban is. Olyan hiba, amire azt mondanád hogy mi a f.sznak nem tesztelték ezt le?

Egy ideje (mondjuk pár napja) felfigyeltem rá hogy a laptopommal az otthoni wifi gyakorlatilag használhatatlanná vált. Boot után 2-3 másodpercig működött, majd ennyi. Az alábbi részlet ismétlődött a végtelenségig:


[ 96.661824] iwlwifi 0000:02:00.0: Microcode SW error detected. Restarting 0x2000000.

[ 96.662001] iwlwifi 0000:02:00.0: Loaded firmware version: 34.0.1
[ 96.662007] iwlwifi 0000:02:00.0: 0x00001007 | ADVANCED_SYSASSERT

[ 96.662387] ieee80211 phy0: Hardware restart was requested
[ 114.018975] iwlwifi 0000:02:00.0: Microcode SW error detected. Restarting 0x2000000.

Mivel semmiféle konfiguráción nem változtattam, illetve a lakásban levő többi ~10 eszköz hibátlanul fent van, közte maga ez a gép is a dual boottal indított Windowsban, rögtön jött a sejtés: kernel vagy linux-firmware csomag. A hardver Intel 8260, a rendszer pedig Arch. Ennek megfelelően a driver az iwlwifi, ami bizony használ blobokat a firmware pakkból.

Az Arch-ról tudván levő, hogy rolling release modellt követ, azaz a kernelt és a firmware csomagot ők szépen frissítik minden más mellett is, méghozzá bármikor. Ugyanakkor elméletben a mindenkori stable ág tesztelt, összecsiszolt csomagokat tartalmaz, mert átmegy a testing repón is a cucc. A reggeli kávém mellé le szoktam tudni egy rövid, 10-20 másodperces ceremóniát a frissítésekkel, hogy ne torlódjon fel sok frissítés, és ez így volt az elmúlt napokban is.

Szóval a fentiek figyelembe vétele mellett a következőkkel próbálkoztam:
- linux helyett linux-lts kernelre váltás (4.15 -> 4.14), ez viszi magával az nvidia-lts és a virtualbox-lts csomagokat is, tehát egy picit el kell szöszölni vele
- linux-firmware csomag downgradelése
- a /lib/firmware alatt kikotorni hogy pontosan melyik ucode fájlt tölti be. Megtaláltam, és láttam hogy számos verzió van ott, úgyhogy egyesével elkezdtem a frisseket törölgetni, hogy lépésenként a korábbit használja
- mivel a dmesg szerint valami hardware restart volt, azt gondoltam hogy a wifi hwkey/rfkill környékén kell keresgélni, úgyhogy megpróbáltam az rfkill illetve a hp-s kernel modulok blaclistjét, hátha
- körbenéztem az iwlwifi kernel modul paraméterei között, volt valami firmware restart letiltás
- kínomban még az ndiswrappert is kipróbáltam (fiatalok kedvéért, ezzel a cuccal haszáltunk windows-only wifi kártyákat a 2000es években), de nem sikerült használni, így inkább dobtam, jobb is :)
- felraktam az inteles friss cpu mikrokódot, meg beraktam az initrd-be. Nem tudom miért, csak úgy.

A fentiekkel elment vagy 2 óra, amit amúgy a szakdogám csiszolásával kellett volna töltenem, eredmény nélkül. A k...a any.d.

Elkezdtem keresgélni is persze. A fenti hiba úgy tűnik hogy a kernel illetve a firmware frissítések miatt úgy 1-2 évente tömegesen felmerül, majd elmúlik (függően hogy a mainstream distrok éppen melyik verziót szállítják). Mivel intel hardverből van egy sz.rrakásnyi, meg kernel és firmware verzióból is, elkezdtem a routert nézegetni inkább, hátha találok olyan beállítást amit átbillentve mitigálni lehet a firmware bugját, mégsem okoz hátrányt sem a laptopnak, sem a többi wifis eszköznek. Volt akinek az vált be, hogy az AES+TKIP opciót AES-re állította át. Akár el is hiszem, fura világban élünk.

Elsőnek a Wide HT40 csatornát átraktam Full 20-ra, a BGN-Mixed módot pedig G-Onlyra. Megjavult. Nincs kedvem utánajárni a továbbiakban. A wifis eszközeimnek elég az 54 mbit, ahol kell a speed, azok úgyis vezetéken vannak. Köszönjük Emese..

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

> Hivatkozzuk be ezt a posztot nyugodtan amikor véresszemű Pistikék előjönnek azzal, hogy a Linux és az open source hibátlan.

Merre találom a kódját a firmware-nek?

Nem világos, hogy a kernel vagy a firmware verzió okozza-e a problémát. De a firmware valóban zárt, ugyanakkor az Arch Linux karbantartóit is terheli a felelősség, mert nem nagyon tesztelik le, csak csomagolják, és "trust me bro" szintű a QA.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

A rolling release diszkrét bája...

Nézd, 2013 óta nyomatom, több gépen, munkában is. Összességében megéri. Ehhez hasonló hibák nagyon ritkán vannak. És tuti, hogy hamarosan javítják, addig meg elvan graceful mitigálva :)

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

"amikor véresszemű Pistikék előjönnek azzal, hogy a Linux és az open source hibátlan" vs az Intel wireless firmware se nem linux, se nem open-source.
Továbbá: egy olyan community rolling distro esetén konkrétan szerinted hogy kéne történnie a lehetséges kernelek és firmware-ek folyamatos tesztelésének az összes elképzelhető konfigurációval?
IT területen írsz szakdolgozatot?

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Nézd, neked is megírom, a linux-firmware-ben található intel mikrokód valóban egy blob, de lehetne azért tesztelni jobban. Az arch bug trackerben számos releváns hibát nyitottak az évek során, általában az a válasz hogy mi közünk hozzá, mi csak terjesztjük.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Félre ne értsd: a szempontjaidat értem, nem akarlak lehülyézni. Viszont a tesztelési elvárásod szerintem idealista, közösségi alapon kétlem, hogy megvalósítható lenne.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

" a lehetséges kernelek és firmware-ek folyamatos tesztelésének az összes elképzelhető konfigurációval?"

Nem egészen értem a problémát. Hivatalosan támogatott kernelből talán kettő van (linux, linux-lts), firmware csomag egy van. Elég a mindenkori legfrissebb hármas vektort tesztelni, oszt kész.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Mindezt nehany tucat processzorral, par hetes stressz-teszttel - tenyleg ilyen nehez ezt felfogni?

Elég sok hardverhez van elég sok firmware (az iwlwifi csak egy példa), ráadásul a kernel konfiguráció is befolyásolhatja 1-1 eszköz működését. Nekem mondjuk volt olyan problémám, amit nehezen találtam meg: végül kiderült, hogy a hardveres virtualizáció támogatásának bekapcsolása mellett mindenféle hibaüzenettel nem működik a 7260-as Intel kártya iwlwifi-vel.
Szóval szerintem elég sok lehetőség van. A koncepciódat értem és gyanítom, hogy nincs elég erőforrásuk (ember, idő) a tesztelésre.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."