Laptop leáll rendszeresen

Már egy ideje küzdök egy ASUS TUF A15 laptoppal, amiben Ryzen 6800H van, Radeon 680M integrált GPU-val. Egy ideje hardveresen is hulladék, rossz az egyik zsanér, meg az aksi is meghalt, de 1 éve használom így, rendben volt. 4-5 hónapja viszont elkezdett Arch Linux alatt szórakozni, fagyogatni, meg újraindulni, néha X és böngésző crash-elt. Ez be is volt tudható a rendszeres amdgpu kernel bugoknak, amikkel a 6.10 óta szenvednek userek a mai napig, a bugtracker-ek tanulsága alapján is tömegesen, így nem aggódtam.

Viszont most a 6.12 és 6.13-as kernellel azt csinálja, hogy nem csak lefagy, hanem néha leáll, értsd, nem szabályos leállás, hanem mintha áramot vesztene, táp kihagyna. Rendszertelenül történik. Nem hibernálok, nem használok sleep-et, se, Wayland helyett is csak X.org megy, egy szál bspwm + polybar kombóval, se kompozitor, se más bonyolítás nincs.

Sajnos dmesg-ben, journalctl-ben, X.org logokban nincs használható, mert nem tud semmi lemezre vagy képernyőre írni, hiszen a rendszer azonnal lefagy, leáll, így diagnosztizálni is egyre nehezebb.

A kérdésem inkább elméleti mégis. Tud szoftveres-kerneles bug ilyen leállásokat okozni? Mert ilyet nem láttam még, mióta 37 éve PC-kkel foglalkozom. Fagyást, újraindulást láttam már szoftveres hiba miatt, de ilyen leállásokat csak konkrétan hardveres hiba esetén tapasztaltam, főleg tápnál, ritkán halódó alaplapnál.

Hozzászólások

A 6.12 kernel LTS, amivel próbálom, fent van a legújabb AMD firmware csomag is, sőt a legújabb AMD CPU microcode is. BIOS-t nem tudok frissíteni, mert érzi, hogy nem jó az aksi, és amíg nincs legalább 80%-os töltöttség rajta, hiába van az elektromos hálózatra csatolva a gép, visszavágja a BIOS frissítést.

The world runs on Excel spreadsheets. (Dylan Beattie)

amíg nincs legalább 80%-os töltöttség rajta, hiába van az elektromos hálózatra csatolva a gép, visszavágja a BIOS frissítést

Ez mondjuk egy zseniális tervezett avultatós mozdulat. Mert ha behal a jövőben az akku (egy akku sem örökéletű ugye, a laptop viszont mehet még nagyon sokáig tovább), és szabad döntésedből desktop gépként használnád tovább akku nélkül, és neadjisten lesznek hozzá még jövőben bios update-k, akkor elvág azoktól a gyártó, amíg nem veszel bele jó drágán működő (neadjisten gyári) akkut.

Lehetne bele másikat kapni, ki is van nézve, de nem merem berendelni, mert ha amúgy is kuka a gép, nem költenék aksira 80 fontot. Ja, szar. Tudom, hogy ez a gép is egy szar már, hogy a bele ki van, de nekem eddig megfelelt, teljesítményre még sok évig overkill lenne. Csak ugye elkezdett szórakozni.

Le fogom cserélni, valószínű egy asztali géppel, ami máris megvan, csak egy portable monitor kell hozzá, hogy kiváltsa nekem a laptopot.

The world runs on Excel spreadsheets. (Dylan Beattie)

Nem lehet, hogy az egyébként is halott aksi csinál random zárlatot, ezzel elvéve a gép tápját? Tud az ilyen dolog szép dolgokat művelni.

hasonlot tapasztalok egy regi dual-boot-os lenovo thinkpad-on.

linux alatt neha random reset-elodik, kulonsen nagyobb terheles alatt, windows alatt viszont soha.

semmilyen nyomot nem sikerult a logokban talalni, hogy mi okozhatja.

A reset nem aggasztana, az lehetne szoftveres bug, arra fel vagyok készülve, hogy most az amdgpu-s kernelfejlesztőknél elgurult a gyógyszer. Ami engem aggaszt, hogy leállások is elkezdődtek, ami viszont már tényleg nem szoftveres hibára utal. Persze a hardveres hiba is lehet olyan blődség, hogy csak nem érintkezik a laptopba dugott tápcsatlakozó, ki lehet kopva a vége, és ha véletlenül elmozdul egy kicsit, akkor az okozza a kikapcsolást, esetleg a töltő kábele van megtörve.

Először egy amdgpu.ppfeaturemask=0xfff73fff kernelparaméternél kezdett kikapcsolgatni, 1 hete (mikor a X.org indult), de azt kiszedtem, egy korábbi debug miatt kellett, akkor nem állt le, de most random elkezdte, már egy kernelparamétert se használok a root= paraméteren kívül, hogy megtalálja a rendszerpartíciót, de semmi más mókolás nincs, se paraméterekkel, se spéci konfig nincsen, minden default Arch által szállított értékeken van. Most egyelőre letiltottam a Testing tárolókat is, és visszaálltam Core/Extra alaptárolókra, downgrade-elve az érintett csomagokat, egyelőre még nem állt le újra, de aggaszt.

The world runs on Excel spreadsheets. (Dylan Beattie)

Bizony tud a kernel is ilyet előidézni, nekem - ugyan Xen alatt, és Intel CPU val - de a CPU power managementtel kapcsolatos bug/incompatibilitás okozott csinált hasonló tüneteket egy Lenovo P52-es.

 

Persze ez rajtad nem feltétlenül segít, mert más az arch, meg más gyártó is... de azt megerősítem hogy nem feltétlenül hardverhiba.

És persz az ilyet debugolni is kva nehéz mert nincs se kernel pánik, se log, se semmi, csak hard reset.

Kösz szépen, erre voltam konkrétan kíváncsi, mert gyanítom, hogy ez is kernelbug, csak egy újabb. Viszont nem tapasztaltam még más gépen ilyet, de ha te is megerősíted, elhiszem.

Nyilván a problémát logok nélkül nem lehet diagnosztizálni, azt nem várom el tőletek, hogy a jósgömbbe nézzetek, anélkül is tudni, hogy az amdgpu driverbe behozott új energiatakarékossági funkciók közül lehet valamelyik a ludas. Kéne csinálnom kernel bisectinget, de nincs olyanban tapasztalatom, és temérdek idő kell hozzá, főleg mert a hiba random, hol előjön, hol nem. Ha nem javul, előbb át kell álljak egy konzervatív disztróra, ha ott is utolér, akkor FreeBSD-re, amit nagyon fogok sajnálni.

Tényleg nem értem, mert 9 éve használok Arch-ot, és ebből vagy 6-7 éve Testing tárolókat, és így még sose lettem megszopatva. Amik előjöttek kisebb gondok, azokra mindig volt egy kis workaround, egyik se volt dealbreaker, meg nem okozott bootolhatatlanságokat, fagyásokat, adatvesztést, stb..

The world runs on Excel spreadsheets. (Dylan Beattie)

Annyit még írnék, hogy nem túlmelegedés, vagy feszprobléma, azokat monitorozom, és minden gyári értéken fut, BIOS alapbeállításon, semmilyen tuning vagy spéci fancurve vagy spéci energiaprofil nincs bekapcsolva. Nem is terhelésen jön elő, hanem csak üresjáratban, mikor vagy nem használom a gépet, vagy csak alig fut valami.

The world runs on Excel spreadsheets. (Dylan Beattie)

Szerkesztve: 2025. 02. 18., k – 16:58

Ugyanúgy 6800 (HS). Windows alatt hetente 1-2x merevre fagy az egész, windows 11 alatt. Yoga Slim 7 Pro X (14ARH7). Hálókártyát már cseréltem, kicsit javult. Kiegészítő videókártyát letiltottam a bios-ban. Memória hiba nincs. 

Azt vettem észre, hogy főleg youtube és hasonló videónézés után szokta összefagyni magát, de érdekes módon Netflix alatt ilyet még nem csinált. Lehet hogy a CPU-ba épített videókártya a ludas?
 

Ú, az húzós. Kösz, hogy írtad, akkor Win alatt nem is tesztelem. memtest-et azért le fogok nyomni.

Ebben is van dedikált GPU, NV 3050 Ti, de az Linux alatt nincs használva, sőt, le is van tiltva a /sys/devices/platform/asus-nb-wmi/dgpu_disable sysfs interface-en, hogy ne kavarjon be semminek. Windows 10 alatt használtam csak az NV GPU-t, de már 1 éve be sem bootoltam rajta Windowst, csak ott hever egy másodlagos SSD-n.

Igen, szerintem a prociba integrált Radeon GPU a ludas.

The world runs on Excel spreadsheets. (Dylan Beattie)

Igen, szerintem a prociba integrált Radeon GPU a ludas.

Egyáltalán nem biztos, lehet hogy a 12 és 13-as kernelbe raktak valamit az energiagazdálkodással kapcsolatban.

Ez összefügghet azzal hogy az akku ócska. Próbáld meg a processzor energiatakarékos állapot C-state beállítani 1-re "echo 1 | sudo tee /sys/module/processor/parameters/max_cstate" így fogyaszt, de lehet hogy nem kapcsol ki.

Meg a proci pihenését is kapcsold ki, ez is összefügghet, a szar akku és kernel "echo "nomwait" | sudo tee /sys/module/kernel/parameters/idle"

A /sys/module/kernel/parameters/ mappában nincs nálam idle, ezek vannak helyette:
consoleblank
crash_kexec_post_notifiers
ignore_rlimit_data
initcall_debug
module_blacklist
panic
panic_on_warn
panic_print
pause_on_oops

A /sys/module/processor/parameters/max_cstate létezik, jelenleg 8-on van, de nem engedi módosítani, még root-ként sem, se sudo-val, se su-val, se rootként bejelentkezve, azt írja vissza a bash, hogy /sys/module/processor/parameters/max_cstate: Permission denied. Lehet ezt körbe lehet kerülni, ha bootparaméterként viszem be, ahogy nézem processor.max_cstate=1 a formátuma, próbálom úgy.

The world runs on Excel spreadsheets. (Dylan Beattie)

Ja, meg is találtam, be is tettem a bootloader-ben kernelparaméternek, újra is bootoltam, de újra fagyott pár perc múlva. Ez ugyan nem teljesen pozitív, de kisebb előrelépés, hogy most nem kivillant a gép, hanem csak fagyott.

Kaptam közben olyan tippeket is máshonnan, hogy a SSH-t engedélyezzem a gépen, és egy másik gépről logoljam folyamatosan a kernelkimenetet terminálban, hátha úgy el lehet csípni még a legvégén a kernel panic-ot vagy crash dump-ot, hogy legyen valami hibaüzenet. A másik, amit javasoltak, hogy engedélyezni a sysreq funkciót, és fagyás esetén a SysReq billentyű megnyomása után bevinni a reisub billentyűket szép sorban, kis szünetekkel, úgy hátha lemezre írja még a cache-t, mentődnek a logok, és szabályosan leválasztja a fájlrendszereket, ezt is ki fogom próbálni.

The world runs on Excel spreadsheets. (Dylan Beattie)

Nekem hasonló konfigurációjú desktop gépnél csinált ilyet az Ubuntu 22 valami 5.x kernellel. Tipikusan akkor történt a fagyás, ha felálltam a géptől és 15 - 20 perc múlva folytattam volna a munkámat, de már nem élt a gép. Természetesen semmi jele nem volt a logokban, csak a normál működés és az újraindítás.

A Win10 ugyanazon a gépen nem fagyott. Akkor rákeresve egy kernel bug volt ami a CPU frequency throttling beállítása miatt fagyott (tipikusan amikor idle-re vált a CPU, megpróbálta visszavenni a frekvenciát és belefagyott). Akkor egy cron-ból indított stress parancs egy szálon gondoskodott arról, hogy ne unatkozzon a CPU, így ment sokáig.

A v6.x kernelek óta nem volt szükségem erre trükkre. 

Nem biztos, hogy releváns, de érdemes ezt a lehetőséget is kipróbálni.

Jogos, de engem a munka (hatékonysága) alapján fizetnek és a sorozatos lefagyások elég sokat rontottak ezen, a bosszankodást nem is számolva. Az a többlet energia amit elfüstöltem a napi 3x15perc szünet alatt az mérési hibahatáron belül van. 

Mindegy a 6.x kernel óta már nincs ilyen probléma.

Házi feladat: mérd meg, hogy a stress -c 1 mekkora energiatöbblettel jár a Ryzen 6 magos 12 szálas prociknál ha egy random Ubuntu matat a háttérben. 

Amiket írtál, az alapján simán hardver hiba is lehet. 
- ha nem jó valami a hűtéssel, hiába látsz átlagosan jó hőmérsékletet, de egy terhelés tüske miatt a védelem lekapcsolhatja a gépet.  Ez akkor is előfordulhat, ha a kernel szoftveresen nem tud elég gyorsan reagálni, de kikapcsolta a hw power mangementet. Régen intel procival volt egy időszakom, hogy kernel paraméterrel kellett kikényszeríteni a hw power managementet, mert a kernelből nem tudott időben lassíteni és a hard limitnél lekapcsolt a gép.

- ha rossz az akku, akkor lehet a gép több áramot próbál használni néha, mint ami a töltővel rendelkezésre áll. Ez szintén változatos hibákat vagy lekapcsolást okozat. A bisoban ha van csendes / takarékos mód, esetleg az segíthet a teljesítmény rovására. A gyári 240W-os töltővel használod? Nem lehet az instabil/hibás?