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)
Flashrom nem viszi?
Ha kicsomagolod a bios.exe -t --force xxx stb paraméterrel lehet indítani akku nélkül is a frissítést, olvass utána.
olvass utána
Ha jófej akarsz lenni, adhatnál egy direkt linket. Nekem nincs ilyen gépem, de mikor néztem az asus oldalát, nem egyértelmű (legalábbis nekem) h. ez a fícsör létező dolog.
kb 5 éves kalandom volt, valamelyik fórum mélyén találtam megoldást
Olyat is látni, hogy régebbi fajta biosnál az easy flash felületen a "risky" szót begépelve felülbírálja. Valsz angol kiosztás számít, riskz
https://www.youtube.com/watch?v=9azao-NWjp8
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.
De, lehet, de akkor miért most kezdi? Az aksi már majdnem 2 éve rossz benne, de nem lehet kivenni, mert ha kiveszem, akkor be sem indul a gép konnektorból sem. Ezt a leállást csak néhány napja játssza.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Mert most rosszabb lett. A rossz akksit a lehető leghamarabb cserélni kell, mert az ilyennek a romlása nem áll meg magától. Mit mondjak neked, mint a kicsit rohadt alma: ha tovább hagyod az asztalon, csak tovább rohad. Azért most kezdi, mert most romlott le annyira az állapota, hogy ilyet okozzon.
Te magad is írod, egy öreg gépről beszélünk, ami egyre szarabb és szarabb állapotban van. Igazából inkább az a csoda, hogy eddig bírta...
Hogy legyen valami pozitív is itten: csinálj egy screen-t a háttérbe, ami 2 másodpercenként elsüti a "sync" parancsot (screen -dmS syncer bash -c "while sleep 2; do sync; done") ezzel megnyered a leállás előtti 2 másodperc logjait a disken, hátha kiderül valami más baj is.
De ha valamennyire szereted még a gépet, érdemes minimális pénzt rááldozni, hogy rendberakd: új (kevesebbet használt) akksit bele, esetleg a zsanért megcsináltatni (egy esetlegesen megtört kábel is tudhat zárlatot okozni). Ezek jellemzően nem olyan nagy összegek, hogy ha a gép amúgy még alkalmas valamire, ne érné meg kifizetni őket.
Blog | @hron84
via @snq-
Ez is egy lehetséges forgatókönyv az akkura: Az akku rossz, rosszabb, egyre rosszabb végül totál rossz és már zárlatos is.
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox
Aksi nélkül tápról mennie kell(ene). Ez alapján arra gondolok, hogy a töltőáramkörben lesz a bibi.
Ha van adapterről feszültség, akkor onnan megy a gép és tölti az akkut, ha nincs, akkor akkuról megy.
Nincs olyan opció, hogy akku nélkül ne menne. Azt viszont el tudom képzelni, hogy látszólag tápról megy, csinál egy hibás akku kapacitás kiírást, de valójában az akkuról megy a géped, amit próbál töltögetni az adapter és csak addig megy, amíg az utolsó elektront ki nem szipkázta.
Windows alatt az aktuális könyvtárba a "powercfg /batteryreport" letesz egy html fájlt az akku adatairól.
Ott látszik, hogy mennyi a jelenlegi kapacitása és hogy mikor mennyit tudott beletölteni.
Ez a leírás szerepel a Wikipédia oldalán az "Elromlott" szócikk alatt
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)
Látatlanban tipp: cpufreqd-t tedd fel + rakj fel valami hőmérséklet monitorozo cuccot, és nézegesd a CPU / baseboard hőmérsékletét. Sokan elfelejtik, hogy a mostani gépeken van ám BIOS is, és vannak olyan gépek, amikben van egy olyan automatizmus, hogy ha a CPU vagy a gép X hőfok fölé akarna menni, akkor lekapcsolják az egész hóbelevancot, akár adatvesztés árán is, mert ha mondjuk kigyullad a gép, nagyobb kár is keletkezhet, mint pár órányi elveszett munka. A cpufreqd segít visszafogni a CPU órajelét, ha nincs rá szükség, a monitoringgal meg tudod nézni a cucc hőmérsékletét, de van egy tippem, hogy emiatt áll le. Windows alatt automatikusan szokott lenni olyan driver, ami visszafogja a frekvenciát.
Blog | @hron84
via @snq-
Ez nekem új és elég meredek állítás. Van erre linked?
Mert az, hogy - ezt teszteltem - 106C-ig hevítettem a CPU-t laptopban (Intel) és ott leszabályozott az bizony valós, de esze ágában sem lett volna kigyulladni vagy elfüstölni. Az évtizedekkel ezelőtt volt, amíg nem volt bennül hővédelem.
minden procifajtához van specifikálva max hőfok. Elvileg azt nem szabad elérnie, mert előtte lelassítja akár a proci hardveres, akár a kernel szoftveres managementje. De van egy hard limit is a prociban, amit elérve lekapcsol a gép. Maga a proci ad ki elektronikusan jelet valamelyik lábán, ami hw leállást jelent. Ha túl gyorsan melegszik fel, mert például hibás a hűtő vagy szoftveresen beakad valami, akkor elérheti.
Amd-nél nem tudom pontosan hogy van, évekkel ezelőtt, talán az intel i7-3720qm -nél még simán volt valamelyik kernellel hiba. Általában a cpu saját hw managementjét kikapcsolja a kernel, mert jobb teljesítményt lehet elérni driveres megoldással. Ilyenkor csak a hard limites lekapcsolás védvonal van. De probléma esetén (bugos, nem elég gyorsan reagáló driver) hamarabb eléri a hard limitet és a cpu hővédelme leoldja a gépet. Akkor a hardveres mód kikényszerítése segített nekem, míg későbbi verzióval már megint jó volt a driveres is. https://www.kernel.org/doc/html/v4.12/admin-guide/pm/intel_pstate.html
Ahogy látom, amd-hez is van hasonló amd-pstate
https://docs.kernel.org/admin-guide/pm/amd-pstate.html
valamelyik módja ennél is gondolom az, hogy a hw kezelje és ne a kernel driver az órajeleket, throttlingot
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.
zrubi.hu
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)
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, ebben is egy dedikált 3050-es van, az első dolgom volt letiltani. Nekem nagyon úgy tűnik hogy az integrált Radeon GPU-nál rontottak el valamit.
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 "e
cho "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)
boot param: processor.max_cstate=1
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)
Ez így Slackware alól szedtem ki neked, nekem ezzel az Intel i3-8130U CPU "csak" 800 MHz-n ketyeg alapból.
Ez egy jó ötlet, ezt még gyorsan kipróbálom, de én pont a fordítottját fogom csinálni, performance-ra fogom tenni, hogy ne engedje pihenni a procit. Ugyanis itt pont valami energiagazdálkodás okozza gikszert, ha még energiatakarékosabbra kapcsolok mindent, az pont, hogy várhatóan nem javít a problémán, hanem ront.
Bár ma az zavar, hogy nem csináltam semmit tegnaphoz képest, és ma nem volt egy fagyás-leállás se. Fene se érti ezt, hogy ilyen random. Jó, a sysreq paramétert engedélyeztem, de az nem csinál semmit, csak fagyás esetén használnám, próbálnám vele szabályosan leállítani a rendszert.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
volt ma lts kernel frissítés. lehet ez az oka.
Ehhez olyan bios kell amiben szabályozható, ott typical-ra vagy hasonlóra kell állítani hogy a kernel lássa.
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.
Akkor egy cron-ból indított stress parancs egy szálon gondoskodott arról, hogy ne unatkozzon a CPU, így ment sokáig.
Azta, jó energiahatékony workaround! :)
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.
Házi feladat: mérd meg
Nem kell megmérni. Tudod mennyi a TDP. Azt leosztod 6-al, ebből megvan h. 1 core mennyi kakakót szokott kapni, ha max-ra terheled. Na annyival több.
Windows XP a megoldás.
Az MS-DOS 6.22 jobban hangzik, jóféle Win 3.11-gyel. Az XP bloat meg fősodratú :D
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Az akku nem kezdett el dagadni és nyomni valamit?
https://iotguru.cloud
Ez jó ötlet, meg fogom nézni. Lehet csak holnap tudom szétszedni, mert egy csavarral cseszekedni kell benne.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
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?
Pont ez aggaszt, hogy lehet ez is, de valami azt súgja, hogy az mégis nagy véletlen egybeesés lenne, mikor pont amdgpu-val el vannak szaporodva mindenkinél a fagyós-újraindulós kernelbugokl, pont akkor megy tönkre az enyém is.
Az akkut meg fogom nézni, még nem volt időm cseszekedni a bent ragadt csavarral. Amúgy a gyári töltővel használom, amivel a gép jött. A BIOS-ban lévő energiamódokat (Silent, Balanced, Turbo) már próbáltam, ugyanazok vannak Linux alatt is, lehet váltogatni közöttük a sysfs-be cat-elve. Egyik se segített, leállás, fagyás volt mindegyik energiaprofillal. Nem számít neki. Talán akkor nincs csak ilyen tünet, ha a gép nagy terhelés alatt van, játszok, vagy tömörítés megy, érdekes akkor sose fagyott le, sose állt le, csak mikor a gép pihen, alig van terhelésen (pl. csak egy böngésző fut, én meg csak egy szál terminálba gépelek), nem is használom esetleg.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Másik ötlet, ha véletlenül virtualboxot vagy azt használó dolgokat használnál, az is okozhat vicces tünetet, amikor elfogy a memória :D Vagy bármi más olyan progit, ami nem swappelhető. Vagy ha nincs swap bekapcsolva. Persze ettől power offnak nem kéne történnie.
Android fejlesztő koromban Genymotiont használtam, ami virtualboxot futtat. És időnként random full csontra fagyott a gép mukna közben, de úgy, hogy log sem íródott már. Némi nyomozás és értetlenkedés után kiderült, hogy a virtualbox memóriafoglalása nem swappolható ki linuxon, hanem mindig igazi memóriában marad. Így ha az felette az összes ramot, akkor az összes többi rendszerkomponens közül próbálta az oom killer lelőni valamelyik processzt, de úgy belassult, hogy minden megállt, még a log írás is. Ráadásul a logok alapján akkoriban pont volt egy ext4gyel kapcsolatos kernel bug is, amit egy paraméterrel lehetett workaroundolni, először azt hittem az okozza. De utána is volt fagyás... aztán olvastam hogy nem swappelhető ki... De persze lehet teljesen más gondod, ez csak egy vak tipp.
Még annyi ötlet, hogy ha terhelés alatt nem fagy,, az jeletheti azt, hogy frekvencia váltáskor hibázik valami. Mert laza terhelésnél fel-le járhat a cpu és ram órajel is. Ami elég sunyi hiba is lehet, ha a ram például bizonyos esetben hibázik csak és a memteszt közben meg nem olyan módban van a freki.
Nem tudom van-e bármi spéci tuning profil a ramban vagy sebesség állítás. Ha valami tuning profilos a ram (amd expo), ha magasabb feszen, magasabb frekivel használja, az esélyesebb, hogy hibázik. A 6800h elvileg sima 4800-as ddr5öt kezel (ha nem lpddr5), jedec cl40-es módban talán az alap.
Nekem kínai minipécében van hasonló, 6850h procis, win és proxmox alatt eddig atom stabilak. Bár grafikára, játékra nem igazán használtam.
Erdemes lenne azert kiprobalni Windows-zal is, hogy azzal mennyire stabil. Csak hogy tisztaban legyunk, mennyire Linux specifikus a gond.
Hát, ha eddig jó volt, majd "elromlott", akkor nem hiszem, hogy az OS-sel lenne gond. De első körben egy NEON-nal megnézném: https://neon.kde.org/download
De valószínűsítem én is a hardware (főleg az aksi) hibát.
Egy Linux rolling release eseten azert ez nem ilyen egyszeru.
hát szerintem meg de....
egy régebbi ökoszitémát használó rendszert lehet összehasonlítani egy friss, napi frissétésűvel. Főleg, ha hibakeresésről van szó. Sőt én még egy live BSD-vel is kirpóbálám.
hát azért, ha kernel frissült. Esetleg, ha regebbi kernellel még jó volt, azt könnyű visszaváltani.