5.4.2-es kernel még nem az igazi

Intel N4200-t - i915 - használó pici notebook-omat ma emlékeim szerint négyszer kellett hosszú gombnyomással kikapcsolni. 5.4.2-es kernel, megfagyott a Xorg. Volt, hogy sikerült még konzolra váltanom, ott login, majd az első dolgom egy sync parancs volt. Utána dmesg. A VGA valamelyik részéről azt mondta, hogy hang up. Nem örültem túlzottan. Visszatettem az 5.3.15-ös kernelt, az teljesen stabil.

Azért írtam, hogy akinek i915, vagy efféle VGA-ja, APU-ja van, az maradjon veszteg, jobban jár egyelőre az 5.3.15-ös kernellel. Remélem, észreveszik, s hamar kijavítják a hibát.

Hozzászólások

5.3as széria meg más miatt bajos: https://hup.hu/comment/2401646#comment-2401646 :)
Valahogy nem megy ez az Intelnek mostanában..

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Elvileg azt a hibát az 5.4es fában már javították (ha lesz időm akkor ma ránézek), de nem csodálkoznék ha mást meg eltörtek volna vele..
Majd ránézek a commitokra, hogy milyen i915öt értintő változásokat toltak még be..

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Tegnap a tesztelésig nem jutottam el, de a kernel fát átnéztem:

- 5.4 tartalmazza a https://hup.hu/comment/2401646#comment-2401646 -ben is említett javítást a VGA hibára:

$ git log --oneline --abbrev-commit v5.3..v5.4 |grep 59cd826fb5e7
59cd826fb5e7 drm/i915: Fix PCH reference clock for FDI on HSW/BDW

- Meg egy csomó mást is: 

$ git log --oneline --abbrev-commit v5.3..v5.4 |grep -c drm/i915
692

- Van nem 1 hanggel kapcsolatos, de a pontos hiba / stack ismerete nélkül nehéz lesz pontosan megmondani melyik kódrész / commit okozhatta nálad ezt..
 

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Úgy emlékszem, valóban valami drm volt. Őszintén szólva nem nagyon van kedvem amortizálni a filerendszeremet azért, hogy jelezhessem a bugot. Ráadásul képes annyira megdögleni, hogy már konzolra sem tudok váltani. Bár többnyire még sikerül.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az i915 driver a drm ágon belül található, szóval nem meglepő, ha arra referált.. Ha esetleg van kedved/időd, akkor pattints fel egy kdump-os kernelt, pakold fel a kdump-tools csomagot, idézd elő a hibát, aztán a crash tool-al rá lehet nézni, hogy pontosan hol is szált el a kerneled..

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

5.4-es ágra biztosan nem fogok frissíteni a kis Pentium N4200-t tartalmazó gépemen. Viszont az 5.5-rc4-et lefordítottam rajta. Mondjuk a munkaidőm végéig nem készült el, a *.spec file-hoz nem nyúltam, így ki tudja, hány architektúrára készül el. Holnapra remélem, elkészül. Aztán megnézem, mit alakít.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Válaszolok magamnak. Agyon verném azt az aljas férget, aki kitalálta a biztonságra hivatkozással, hogy kell az EFI/UEFI, meg minden legyen aláírva. Miért is írom ezt? Lefordult az 5.5-rc4-es kernel, az rpm csomagok szépen előállítódtak. Fel is telepítettem a gépemre. Aztán reboot, majd közli velem, hogy invalid signature. Hát, ezt a kernelt sem fogom elindítani. :((

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nekem nincs bajom az 5.4.2-es kernellel :) Pedig van AMD/Intel vegyesen amin fut.

Az elmélet az, amikor mindent ismerünk, de semmi nem működik. A gyakorlat az, amikor minden működik, de senki nem tudja, miért.

Centos 7-esen elrepo-bol hasznalt kernel-ml teljesen stabilan megy egy J3455-os Gigabyte lapon (igaz, kb 2 napja raktam fel csak).

AMD gépen, nVidia VGA-val, nouveau driverrel nekem is jól megy az 5.4.2-es kernel. Ez szerintem specifikusan i915 driver regresszió lesz. Mi több, az is csak speciális esetben. Használom a barrier nevű kvm software-t, ezzel meg lehet oldani két gép között - akár Windows és Linux között is! - a billentyűzet és egér megosztását. Az infó értelemszerűen hálózaton megy át. Tehát át tudom húzni a windows-os gép képernyőjéről az egér kurzort a linuxos gép képernyőjére és vissza. :) Nem tudom, milyen függvények hívódnak ilyenkor, ami talán átlagos használat során nem nagyon, de 5.4.2-es kernellel megdöglött, 5.3.15-össel meg nem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nekem is képes volt akár 40 percen át működni. Aztán, amikor megdöglött, online rádiót tudtam még hallgatni tovább, egér kurzor mozgott, de képernyő már nem frissült. Aztán konzolra váltva sync, dmesg, majd ott láttam, hogy a GPU valamelyik része hang up, persze reboot csak elkezdődött, mert gondolom, örökké várt a GPU valami életjelére a driver. Azaz már nem állt le szabályosan, s a logban még látszott, hogy miért. Az 5.3.15-tel ilyen bajom sohasem volt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nekem is van valami Inteles videó nyűgöm, nálam mondjuk Debian 10 gyári kernel van (4.19).

Nem tudom, mitől függ, de sokszor talán hetekig semmi probléma, máskor napjában többször is hasonló jelenséget produkál - egérkurzor mozog, háttérben reagál is, de a képtartalom az egérkurzortól eltekintve változatlan, dmesg alapján GPU problémája van.
...viszont konzolra váltást követően "kwin --replace"-szel újraindítva az ablakkezelőt minden megy tovább gond nélkül, beleértve a futó alkalmazásokat is...

Örülök, hogy segíthettem. :) Munkahelyen használok egy windows-os és egy linuxos gépet, s kellemetlen átnyúlkálni az eléjük rakott vezetéktelen billentyűzeten, ezért használom a barriert. A "barrier kvm" kulcsszavakkal megtalálható, nem keresem most meg, de a hozzászólásodból azt érzékelem, ezen már túlvagy.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerkesztve: 2019. 12. 14., szo - 13:36

Van otthon is egy majdnem uganolyan hardware-ű gépem, azon is előjött a hiba. A gépet hálózaton még elértem, így bizonyos infókat gyorsan kinyertem még belőle, majd hálózaton megkaparintottam tőle, közben szokatlanul gyakran használtam a sync parancsot. Végül sikerült hálózaton keresztül leállítanom a gépet.

Egyébként úgy néz ki, már az 5.3.15-ös kernel is hibás volt, csak ott ritkábban jön elő a hiba.

i915 0000:00:02.0: GPU HANG: ecode 9:1:0x00000000, hang on rcs0
GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem volt ez a hiba benne már korábbi kernelekben is?
Nálam 4.19.0 (Debian alap) kernellel jön elő ilyen hiba, ha az "Intel" drivert használom - vagy legalábbis ez a probléma is az i915 tájékán van.

Debian 9 alatt az nVidia kártyát használtam, Debian 10 frissítés óta beállítottam az Intelt - ezen a gépen a külső kijelző meghajtása az nVidia kártyára van kötve (a DSUB csatlakozót leszámítva), most viszont ezt megoldottam a fogyasztás / melegedés csökkentése miatt.

Ebben a felállásban sokszor hetekig működik, máskor napi ötször újra kell rúgnom az ablakkezelőt (ahogy fent írtam), szerencsére a programokat tovább lehet használni, ezért nem vágtam még ki az egész megoldást.

5.4.2-nél tapasztaltam először. Az 5.4-es korábbi kiadásai nem kerültek lefordításra Fedorára, azaz 5.4.0-val, 5.4.1-gyel sohasem néztem. 5.3.15-tel ezen rossz tapasztalatot követően egyszer előjött a hiba, de tényleg csak egyszer. Korábban talán soha. 5.4.2-nél viszont olyan gyakran, hogy nem tudtam úgy használni a gépet.

Most 5.3.16-ot tettem arra a gépre, de azzal még nem volt sokat járatva. Már csak azért sem, mert az a kernel még csak egy napja jött ki. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

5.3.14 előtti kernelek voltak elvileg a hibásak, legalább is ez alapján:
https://linuxreviews.org/Kernel_5.4.1_And_5.3.14_Are_Released_Making_Li…

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Felületesen átfutottam az elejét. Tényleg arról lenne szó, hogy az i915 driver el tudta érni, hogy egyéb memória írások adott időintervallumban ne történhessenek meg, s ezzel akár a filerendszer konzisztenciának is annyi, meg értelemszerűen bármikor megpusztulhat a gép? S ezt egyesek komolyan is gondolták, mint megoldást?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ahogy én értelmezem egy egy race condition.. A baj ott van, hogy ahhoz, hogy ez elkerülhető legyen megfelelő időben megfelelő erőforrást (memory page) lockolni kéne, hogy egyszerre csak 1 fél használhassa azt egy időben, de valahogy ezt eddig nem sikerült elérni (körkörös dependencia van, ahogy értelmezem, de javítson ki aki okosabb), ez miatt meg ilyen "vicces" dolgok fordulhatnak elő..

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Igen.. Ha átolvasod a cikket, akkor ott le is írják, hogy a a 5.0.21 utáni kernelek a 19.2.x-es  Mesa-val folyamatosan problémásak, egészen 5.3.14-ig (kiegészítés: Nem ez az issue datálódik vissza olyan régre, hanem több issue együttesen érte el azt, hogy folyamatosan legyen valamilyen probléma). Az, hogy ezek közül melyik miként jött elő (illetve mennyi fejfájást okoz(ott)) az már más kérdés.. Egyáltalán nem biztos az se, hogy ez mindenkit érintett volna..

Az viszont eléggé látható, hogy Intel driver szinten most eléggé gyengén áll (és akkor még az i915 vs i965-be bele se mentem :))

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Szerkesztve: 2019. 12. 14., szo - 15:15

Nem ide akartam.

Szerkesztve: 2019. 12. 20., p - 11:28

Fordítottak 5.4.5-ös kernelt Fedora 31-hez. AMD platformon megy, Intel N4200-n a dmesg szerint kétszer megfeküdt 1.3 másodperc környékén. Ettől függetlenül elindult a gép, működik, egyelőre i915 döglés nem volt, de még csak fél órája használom.

Szerk.: Azért ezt a bugot jónak láttam jelezni a bugzillában, tudjanak róla. 5.3.18-ban még nem jött elő, de 5.4.5-ben következetesen megdöglend. Persze ennek ellenére a gép működik. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

[drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for more than 5secs aborting
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing A4C6 (len 84, WS 0, PS 0) @ 0xA4FC
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing D028 (len 525, WS 0, PS 0) @ 0xD099

AMD Ryzen 7 3750H with Radeon Vega Mobile Gfx @ 8x 2.3GHz

Legyen itt jelezve AMD fagyás itt ebben a szálban (jellemzően steam alatt jön elő, játszani már nem kell :)_).

Szerkesztve: 2019. 12. 22., v - 11:30

Tegnap - azaz 21-én - Intel N4200 CPU-n 5.4.5-301-es kernel úgy fagyott szét boot után talán 1 percen belül, hogy csak pislogtam. Olyannyira, hogy hálózaton sem tudtam elérni a gépet, maradt a kikapcsoló gomb hosszan történő nyomása. :(( Vanillában már van 5.4.6-os, nem néztem, miket javítottak, de jó volna, ha végre megint használható lenne a kernel. Várom, hogy fordítsák le Fedorára.

Szerk. 1: A tegnapi kernel halál hagyott nyomot a logban, így ma írok egy megemlékezést erről a bugzillába.

Szerk. 2: Nézve korábbi bugzilla bejegyzéseket, az ilyen típusú hiba valószínűleg memory corruption lehet. Nem a hardware rossz, korábbi kernellel stabil a gép. Úgy tűnik, az 5.4.5-ös kernel összefirkálja a memóriát ott is, ahol nagyon nem kellene. :(

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

5.5.6-201-es build-ben eljutottunk oda, hogy a nyafogásomra - meg másokéra is nyilván - megpatkolták a kernelt, s működik az iwlwifi regresszió javítása, valamint az i915 ha nem is stabil, de nem fagy szét állandóan. Az 5.5.7-200 még jobb, így most boldogság van. :) Végre el tudtam szakadni a régi 5.3.18-tól.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE