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.
Úgy néz ki, ez lett. Mikor írtam tegnap, hogy egész nap végig stabil volt, pedig nem csináltam vele semmit, kiderült, hogy nem igaz. A pacman log szerint tegnap reflexből telepítettem update-ekkel a 6.12.15-ös LTS kernelt, ami váltotta a 6.12.12-őt, és ma sem volt se fagyás, se leállás. Végig problémátlan a gép, 2 napja, innen gyanítom, hogy nem hardverhiba. Ha hardverhiba lenne, akkor minden X. percben csinálná, kb. kiszámíthatóan, és nem az lenne, hogy egyszer szórakozik, aztán napokig jó. A Firefox és a Signal szokott crash-elni, de azok sem csinálják két napja, vagyis ma a Signal egyszer egy üres felülettel fogadott, mikor visszaváltottam arra a virtuális asztalra, ahol az fut, de akkor se crash-elt, ez jó jel.
Mondom, a 6.10-es kernel óta küzdök vele, a 6.11-es széria végén volt pár kernel, amivel nem csinálta, meg most a 6.12 ciklus elején egy párral, aztán elkezdett megint szórakozni, most megint jó.
Hétvégén azért fellövöm rajta az SSH-t, meg szétszedem a gépet, hogy az aksi púposodását ellenőrizzem. Most egyelőre csak a processor.max_cstate=1 (ez bizonyíthatóan nem segített, de még benne hagyom pár napig) és kernel.sysrq=128 paraméterek vannak a bootloaderben hozzáadva, meg belőttem a CPU governort performance-re, de azt csak tegnap, ma már az se volt aktív, mert rebootoláskor elveszik a hatása, ma elfelejtettem belőni, és csak a default powersave governor beállítással ment a gép.
Egyébként az eset miatt sajnos váltani fogok Debian-ra. Ezzel a rollinggal nagy baj nem volt 9 évig, de sajnos a kernelfejlesztőknél lement a színvonal rettenetesen, és azokat a drivereket is kezdik elcseszni már, még az LTS kernelben is, amik régen a legjobbak voltak. Az amdgpu driver hírhedten a legjobb, veri az inteles drivereket is, nem hogy a szutyok nvidiásat, és már ezt is sikerült szétcseszniük, pedig pont azért vettem AMD-s gépet, hogy NE legyen ezzel gond. Sajnos igaza van hajbazernek, nem jó ez a frissességmánia, ma már sokszor nem hogy fejlődés nincs, de visszafelé fejlődés van. Nem érdekel, hogy most látszólag megjavult, már volt az utóbbi időben ilyen pár hetes időszak, amikor jó lett, aztán megint elqródott, megszűnt benne a bizadalmam. Ez nem is a rolling meg az Arch hibája, ez a kernelfejlesztők újfajta debilsége, hogy megy a politizálás, meg a rust-osodás, közben meg leadták a minőséget rohadt durván, és a bugos szutykaikat még az LTS kernelekbe is visszaportolják.
Ha az NV GPU szórakozna, arra azt mondanám, hogy ez ilyen, az egy szar cég, én vettem rossz hardvert Linuxhoz. De itt pont a bejáratott, legstabilabbnak tekintett AMD GPU driver szórakozik, pedig már nem is új, a Ryzen 6800H a bele integrált Radeon 680M-mel 2022-ben jött ki, és mindjárt a kezdetektől stabil volt, egészen mostanáig.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Végre, akkor hallgathatunk Debian siránkozást is.
Szégyen, ahogy fikázod a fejlesztőket akik azért dolgoznak hogy itt siránkozzál, milyen szar is az amit használni szeretsz. Épeszű ember visszavált egy kernel verziót, és nem a HUP-ra jön nyávogni.
Nem, csak én fikázom, csomó ember küzd most ezzel. Mondom, itt nem is az, hogy dolgozik, hanem azt is tönkreteszik, ami már egyszer jól működött, csak annyit kellett volna tenniük, hogy NEM nyúlnak hozzá. Nekem azért ne dolgozzon, hogy bekeverjen.
Továbbá elsiklottál afölött, hogy NEM lehet visszaváltani egy kernelverziót. Eleve máris nem a legújabb kernelt használom (az a 6.13.3-as, ugyanúgy érinti a bug), hanem az egyel korábbi LTS-t (6.12.15), de ezek a bugok a kettővel korábbi LTS-be (6.6.x) is vissza vannak portolva. Ezen igazából már lehet a Debian se segítene, hacsak ott nem a 6.1.x megy, vagy abba is vissza nincs portolva. Tehát nem csak hogy hibáznak a kernelfejlesztők, de már a kellően ki nem tesztelt, vagy már tesztelés alapján bugosnak bizonyult kódot is visszaportolják régebbi kernelekbe.
Arch-on egyébként sem nagyon váltasz vissza te verziót. Mindig a legújabb van a tárolókban, meg van egy a legújabb LTS-ből, és kifújt. Lehet ha AUR-ból összeügyeskedsz valami spéci kernelt, és azt utána tiltólistára teszed a pacman konfigban, akkor jó lesz egy időre, de aztán meg azért fognak eltörni dolgok, mert a túl régi kernelverzió nem fog illeszkedni az újabb csomagokhoz, újabb linux-firmware csomag, glibc, stb.. Hangsúlyozom, hogy ez nem Arch probléma, ez a kernelfejlsztők problémái újabbak disztrótól függetlenül, az Arch csak annyiban különleges, hogy mivel ők bleeding edge rolling, először kapják arcba ezeket.
Azt is leírom világosan, hogy miért nem a kernelesek git issue trackerére jelentem: nincs elfogott hibaüzenet, úgy fagy meg villan ki alólam a gép, hogy a logok nem tudnak a lemezre kiíródni, így meg konkrétum híján nem foglalkoznak általános sirámokkal a kernelesek. Ahhoz kéne egy konkrét, elcsípett hibaüzenet, akár segfault vagy crash dump, akár kernel panic, de valami kézzel fogható, aminek a mentén a kernelfejlesztő elindulhat a debugolással.
Értem hogy te most ilyen nagy Arch rajongó lettél, mint írtam, 9 évig én is az voltam, terjesztettem több témánál is az igét. De az idők változnak, nem is az Arch, amivel annyira baj van (bár a legutóbbi glibc 2.41-es keverésük szintén felillik a szégyenfalra), hanem a kerneleseknél ment le ennyire a színvonal mostanában. Nagy mákod van, hogy téged ez a bug nem érint, mert állati szopás, nem vagyok kezdő, már Arch veterán, és hónapok óta kifog rajtam.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Igen, így van, mert nálam az fontos hogy az amit használok, az azt nyújtsa amit szeretnék. De ha az Arch nem hozza ezt a színvonalat, amit most nyújt, akkor áttérek másra. Ha kell Windows-t használok, ha meg azt kell akkor Mac-et. Nem mintha nem használnám most is párhuzamosan ezeket. Mert nem viszek az informatikába mindenféle begyöpösödött őrületet amit neked percről percre meg kell élned.
De ezt Te soha nem fogod megérteni, mert aki a ~/.cache könyvtár miatt is hisztizik mint egy gyerek akinek elvették a játékát, az nem fogja. Én már akkor is használtam Linuxot, amikor még azt se tudtad hogy létezik. Nem kell játszanod a nagy Arch evangélistát.
Tessék az ok, miért is szeretem ennyire az Arch-ot:
Befejezem, mert biztos hogy annyi és olyan szó hangzott el ami miatt a nyugtatók után kell nyúlnod, mert "elvből" elutasítod.
"Arch-on egyébként sem nagyon váltasz vissza te verziót. Mindig a legújabb van a tárolókban, meg van egy a legújabb LTS-ből, és kifújt."
Ez egyszerűen nem igaz. Nem tudom, hogy melyik Arch alapú disztro fut nálad, lehet, hogy pont Arch neve, nálam Manjaro van.
Simán el tudok haladni a System Setting/Administration/Manjaro Settings/Kernel útvonalon ahol pingvinre kattintva egészen az 5.4.290-2 verzióig lehetőség van visszalépkedni.
Azt gondolom, hogy nálad is megtehető ez a lépés. Legfeljebb nincs ... .... .... hozzá. Válassz a három lehetőség közül 1-et.
Még nincs aláírásom.
Amikor ezt olvastam, nekem az jutott eszembe, hogy azért használ 9 éve Arch-ot, mert még eltávolítani se tudja.
Ja, mint az ember itt a fórumon, aki azért használ vimet mert nem tudja hogyan kell kilépni belőle. (OK, mindenki tudja, hogy csak aláírás, de példának jó :) )
Még nincs aláírásom.
Természetesen korai volt az öröm, 1 órája megint kivillant alólam a gép. Se szó, se beszéd, kikapcsolt.
Ami még kezd gyanús lenni, hogy legtöbbször, mikor megtörténik, akkor gépelek. Elég finoman, tapintós gépírással, nem kopácsolok, de meglehet, hogy akár valami billentyűzet vagy hasonló beviteli periféria drivere is lehet bugos.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Vagy meg van repedve az alaplap es gepeleskor vmi elmozdul, aminek nem kellene. Ezert irtam, hogy probald mar ki Windows-zal is, mert ha azzal is elojon, akkor kizarsz egy csomo linuxos rantot.
De, ez lesz az, mégis hardverhiba és a billentyűzet vagy alaplap a ludas. 3-szor is sikerült egy perc különbséggel reprodukálni, durván flexeltem a billentyűzetet, durván kopácsoltam rajta, morzsolgatom le a billentyűket sokasával egyszerre. Ebből egyszer ráadásul a boot nagyon korai szakaszában reprodukáltam, amikor még csak az initramfs-ből töltődik a kernel, és még csak a sedutil NVMe hardveres titkosításos SSD jelszót kéri be, már ott kialudt a gép, ilyen korai szakaszban még az amdgpu driver, linux firmware se töltődik be.
Windows 10 alatt is tesztelni fogom, meg ránézek az aksira, de úgy néz ki, hogy megvan a ludas. Bocs mindenkitől a hosszú rant-ért, előre jeleztem is, hogy lehet hardverhiba, rossz állapotban van a gép, csak azért gyanakodtam AMD GPU-ra mert a korábbi fagyások és crash-ek okozója az volt, én meg összekapcsoltam tévesen a kettőt. Billentyűzetre se először gyanakszok, de azért vetettem el eddig, mert nagyon tapintva, puhán gépelek, 10 ujjas gépírással.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Olyat is probalhatsz, hogy belepsz a BIOS-ba es ott gepelj/tekergesd a gepet, hogy lekapcsol-e.
Egy külső billentyűzetet rákötnék kíváncsiságból.
Az akkut megnézted már, hogy nem dagadt-e meg?
https://iotguru.cloud
Nem, az ma jön, mindenképpen, a windows-ra átbootolós teszt után. Mint írtam, az egyik csavar a gép alján lötyög, de ki se akar jönni, nehéz kiszedni, nagy küzdelem lesz. Nyilván, ha most kiszedem, nem lesz többé visszarakva.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Nem rossz otlet, megnezem.
Sensors-al probaltam mar nezgetni, de eddig semmit nem sikerult talalni.
Bár ez sok segítséget nem jelent számodra, azért leírom: Két dolgot nem veszünk az ASUS-tól SOHA, alaplapot és laptopot. Ezeket baromira imádják fillérbaszásból szeméthalommá változtatni. Ha megspórolhatnak 1 centet, megspórolják, te meg szívsz hogy recseg a hang, instabil a hálózat, törik a zsanér, porlad a műanyag, reped a pcb, bug-os a bios/uefi, ect...
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt. / Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!! / Mindenki jó valamire. Ha másra nem, hát elrettentő példának. / "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993
Hasonló dolgokat produkál a Lenovo Yoga laptopom is.
Lehet ebben igazad lesz. Bár ahogy a kolléga is írta, lassan már az összes ugyanez a fos, Samsung, Xiaomi, Acer, Dell, Lenovo, HP is, a Thinkpad-ek sem már az a javítható, szerelhető, strapabíró, jó billentyűzetes üzleti termékvonal, ami előtte volt, épp az a papírvékony, szigetes billentyűzetes, ragasztott, mindene odaforrasztott kommersz hulladék. Most olvastam, hogy a következő Thinkpad genről már a piros trackpointot is le fogják venni, nincs rá igény a piaci kutatásaik szerint.
Nyilván akkor megbántam ezt az ASUS vételt, mikor 1 hónappal a gariidő után tönkrement benne a kímélt aksi, de onnan nem volt visszaút, mivel működött, nem dobtam ki a gépet.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Kapd szét, tegyél rá egy vaskosabb alu/réz darabot hűtőnek és tedd be két plexi/fa lap közé. Nem annyira vékonykliens, házi szerver letölteni...
Tegyen a kijelző helyére egy tükröt és ajándékozza a feleségének, a billentyűzet helyére pedig pamacsokat és krémeket. Minden nő örülne egy olyan nagy hordozható smink készletnek.
Még nincs aláírásom.
Mondjuk ha az alaplapja szar, akkor nem sok mindent lehet vele csinálni. 6-8 rétegű nyák. Ha csak valami forrasztás engedett el és észrevehető az a jobbik eset.
Én nem annyira viccnek szántam. A melós laptopom egy 8gen i7 + GTX1060 + 16GB DDR4, viszont annyira nincs jó bőrben. Építkezéseken használtam, kapott ezt-azt. Simán csinálnék belőle egy slim asztali gépet. Akár egy monitor hátuljára fel lehetne rakni ilyen csináldmagad egybenpécé! :-D
Volt aki hűtőgépet csinált egy VAX szerverből. Jó sok minden elfért benne. És nem viccelt.
Még nincs aláírásom.