Laptop leáll rendszeresen

Notebook, laptop, mobiltelefon ...

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.

  • 2089 megtekintés

( Raynes v | 2025. 02. 18., k – 16:09 )

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)

Igen, ezt ki is fogom próbálni. Valami hasonlót próbálgattam már anno, de nem működött. Nem emlékszek rá, hogy ez az F11 volt-e az, vagy más.

Amúgy nagy az az érzésem, hogy ez kettős hiba lesz. Egyrészt úgy néz ki, hogy a kernel is valóban bugos, mert a fagyásokat, meg az X crash-eket az okozza. A gépleállás az ettől egy teljesen más probléma, arról bebizonyosodott, hogy hardver eredetű.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( Luckye | 2025. 02. 18., k – 16:15 )

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.

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

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

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.

de akkor miért most kezdi? ... Ezt a leállást csak néhány napja játssza.

Ez a leírás szerepel a Wikipédia oldalán az "Elromlott" szócikk alatt

> Nincs olyan opció, hogy akku nélkül ne menne.

Aktuálisan, láttam már olyan gépet, hogy az akku zárta az áramkört, vagyis ha ki volt véve az akku, de rá volt rakva a töltőkábelre, se kapcsolt be. Ha beraktam az akksit - akármilyen szar is volt - elindult, működött.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( eyez00 | 2025. 02. 18., k – 16:18 )

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

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

ha a CPU vagy a gép X hőfok fölé akarna menni, akkor lekapcsolják az egész hóbelevancot

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

( zrubi v | 2025. 02. 18., k – 16:31 )

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)

( Raynes v | 2025. 02. 18., k – 16:47 )

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)

( sz332 v | 2025. 02. 18., k – 16:54 )

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)

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)

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. 

( azbest | 2025. 02. 18., k – 19:15 )

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.

( asm v | 2025. 02. 19., sze – 08:35 )

Erdemes lenne azert kiprobalni Windows-zal is, hogy azzal mennyire stabil. Csak hogy tisztaban legyunk, mennyire Linux specifikus a gond.

Ú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)

Egyébként az eset miatt sajnos váltani fogok Debian-ra

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)

Értem hogy te most ilyen nagy Arch rajongó lettél

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:

  • Jelenleg: Packages: 1024 (pacman), 25 (flatpak) míg más OS-eken egy alap, üres GNOME is több ennél. Igen, igen tudom, megőrjít a flatpak szó is.
  • Minden hibátlanul fut, és friss, ezt imádom, de ne nem vagyok olyan idióta hogy ész nélkül frissítem. Frissítés előtt boot-olom a backup live ssd-met. Ismerem a Linux-ot, lehetnek hibák. Velem nem történik olyan mint Veled. Maximum, "a faszom" felkiáltással elindítom a restore-t és főzök közben egy kávét.
  • Nálam fontos a virtuális gép, és ez az Arch-ban kimondottan jó. Jó gyors.
  • Be tudtam állítani a diszkrét NVIDIA kártyát. Ez nagy szó Linux-on. De azért ne kapj az NVIDIA szótól agyvérzést, mert láttam ez leköti az agyad rendesen. NVIDIA.
  • Nincsenek fanatikus csípőből elutasító "érzelmeim" ha flatpak-ot kell használni. Jónak tartom, használom. flatpak, flatpak, flatpak.
  • stb. stb. stb.

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.

Nem is baj, hogy míg új neked, lelkes vagy. Majd idővel észreveszed, hogy egyik disztró se hibátlan. Én se véletlenül használtam ilyen sokáig Arch-ot, összességében azt találtam a legjobbnak, leg-bullshitmentesebbnek. Azt is elismerem, hogy a helyzetem komplex, mert a gép is szar, de legalább részben a hibákat kernelbug okozta, ez biztos, a 6.10-től 6.13-ig dokumentálva van több Arch bbs fórumtopikban, és a freedesktop.org-on, a kernel amdgpu bugtrackerében, számos dokumentált eset, hogy ez a 680M meg más integrált és dedikált AMD GPU-k (R9 290, RX 470-től egészen a legújabb Radeon 890M, RX7900-ig minden generáció) és épp úgy random fagyni kezdtek, meg a gép újraindulni, meg böngésző, X szerver crash-elni, ezt tuti nem a hardver miatt volt.

Egyszerűen az AMD GPU karbantartók mostanában nagy kódátalakításokba kezdtek, implementáltak egy csomó izgalmas powersaving feature-t, és ez egy tonna bugot okoz, mert nem tesztelték ki alaposan.

A leállások viszont hardverhiba eredetűek, úgy néz ki. Azért is indítottam a topikot, mert a leállásokból gyanús lett, hogy ez kicsi valószínűséggel szoftverhiba.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

"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.

Ez Arch, nem Manjaro. Nálam nincs is ilyen System Settings, minimalista ablakkezelő meg terminál van. Semmi ilyen GUI-s csodaprogram. Arch tárolóiban nincs más, egy legújabb, meg egy legújabb LTS kernel. Ennyi. AUR-ban vannak mások, de ott is változik, mint a szél, sokszor van, hogy felraksz egyet, és a karbantartója egyszer csak elkezdi elhanyagolni.

Ezt neked semmilyen manjaro-s csoda GUI nem oldja meg, hogy nem létezik más a tárolókban, nem veszi elő a varázspálcát, hogy odavarázsolja.

De mindegy is, mert kiderült, hogy hardverhiba.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

"Nem létezik a tárolókban"

Különösen ironikus ez annak tudatában, hogy évek óta hallgatjuk tőled, hogy GUI-t, Windows-t, stb. csak a hátulgombolósok használnak, de az már nem fért bele a nagy szakértelembe, hogy

pacman -U https://archive.archlinux.org/packages/l/linux/linux-4.20.10.arch1-1-x86_64.pkg.tar.xz

Ennél régebbi tényleg nincs sajnos, meg kell elégedni az alig 7 éves kernellel.

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)

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)

Windows alatt még nem próbáltam, de BIOS-ben igen, ott nem sikerült kikapcsolásra bírnom, bár ez azért is lehet, hogy addigra hajtogatva volt a gép oda-vissza, többször kinyitva, lehet pechemre, mikor a BIOS-ban próbáltam zongorázni, addigra valamit véletlenül stabilizáltam, és azért nem csinálta.

Sőt, most jelenleg Linux alatt se tudom reprodukálni, akárhogy zongorázok, flexelem, nem akar kikapcsolni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

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)

Fa+Somat 2 az 1-ben gazdaságos tabletta. Nem tudom szétszedni, a zsanérnál a két hátsó csavar nem jön ki. Csak forognak egyhegyben, pedig 1) biztosan belevaló csavarok, 2) maga a csavarfejen a kereszt nincs kinyűve, tehát nem az, hogy a csavarhúzó nem tud belekapni, mert van elég forgatónyomaték, de a csavar nem akar kijönni, csak egyhelyben pörög a menetben. Az egyik csavar kijön egy 2 mm-re, de ott elakad, nem lehet kijjebb csavarni, ezt talán fogóval lehet még feszegetni, de a másik még reménytelenebb.

Ehhez szerintem valami ütvefúró kell. Lassan már nem is érdekel, megy az egész gép a szemétre, de mindenképp szét kell szedni, akkor is, ha eltörik, mert az NVMe meghajtókat, meg a RAM-ot kiszedném belőle, a meghajtókat azért, mert kellenének, a RAM meg ér valamit még benne.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ezek általában nem anyás csavarok amennyire emlékszem, hanem sima önbetekerősök. Inkább a menet van elnyalódva valahol, és nem találja a kiutat.

Talán ha finoman körbevágja a műanyagot körülötte, ki lehet szedni - de akkor oda már az életbe többet csavart nem tesz. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Ma tudtam egy hónap múltán kiszedni, az új melóhelyen vannak rendesen szerszámok. Nem volt semmi elszakadva, nem belevaló csavart raktam bele véletlenül, félre voltak téve egy tartóban, de úgy néz ki, hogy keveredett oda más is. Az egyik csak harapófogóval jött ki, a másik meg két csavarhúzóval, az egyikkel feszítettem szét a fedő és alsó karosszériát, a másikkal csavartam ki a csavart, úgy kijött.

Megnézve a gépet belülről, minden normálisnak tűnik, akku sincs felfújódva (persze attól még nem működik egy éve már), persze attól még lehet zárlatos.

A fagyós-újraindulós jelenség megszűnt, az kernelbug volt, a 6.13 tájékán már nem jött elő. A leállásokat viszont hardverhiba okozza, vagy valami nem érintkezik, ki van lazulva, vagy az akku zárlatos, nem tudom, de egyre gyakrabbak a leállások. Legtöbbször, mikor gépelek rajta, de nem reprodukálható. Mindegy, letettem már erről a gépről, csak azért kellett szétszedni, hogy ki tudjam venni az SSD-ket, RAM-ot, Wi-Fi kártyát esetleg. Az SSD-k kellenek a másik gépben, amit ehelyett fogok majd használni.

Egyébként a hajam tépem, mert amúgy teljesen jó laptop lenne, 8 mag, 16 szálas, majdnem 5 GHz-en ketyegű proci, normális RDNA2 integrált GPU, egész használható dedikált GPU, és szépen totálkár az egész, se akku, de most már ki is kapcsolgat egy ideje. Jobb zsanér is ki van lazulva, de az az én hibám, hogy nem csavartam időben vissza a csavarokat bele, meg később a rossz csavarokat, erről a részéről én tehetek, ilyet nem fogok többet elkövetni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Aksi nélkül elindul? Írtad fentebb hogy nem, de biztos nincs ilyen lehetőség? Ha full lehúzod róla akkor megmoccan tápról? Én úgy tudom hogy csak régebbi gépeknél volt ilyen (pl g4 macbook volt talán?) hogy terhelve többet vett fel mint a táp és aksiból "pótolta" a többletet, de manapság már nem jellemző (legalábbis én nagyon rég nem találkoztam ilyennel). Esetleg csinálhatsz belőle desktop PC-t ha éled ezt a DIY dolgot. Lebontod róla laptop mivoltát, tákolsz vagy 3D nyomtatsz neki valami dizájnos kis házikót, teszel rá rendes csendes hűtést, külső monitor/egér/bill/hangfal és kész a mentett asztali PC.

Ezt már csak holnap tudom tesztelni, ma már nincs rá időm. Emlékeim szerint nem lehet lehúzni róla a tápot teljesen, csak az egyik csatlakozót, ha a vezérlő szalagkábelt is lehúzom, akkor nem indul be a gép. Ez tuti nem vesz fel több áramot, mint a táp, mert az aksi rég teljesen döglött benne, abból mindenképp csak 0 áramot vesz fel jó egy éve.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( eyez00 | 2025. 02. 21., p – 08:06 )

Nem rossz otlet, megnezem.

Sensors-al probaltam mar nezgetni, de eddig semmit nem sikerult talalni.

( salaud v | 2025. 02. 21., p – 08:27 )

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

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)

( kleinie | 2025. 02. 21., p – 17:23 )

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...

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

( n.balazs v | 2025. 03. 19., sze – 22:16 )

Ohhh, mindjárt megkapod Treytől, hogy AMD. :)

Egy ötlet, amit gyorsan kipróbálhatsz, ha a gép záros határidőn belül fagyni szokott: lépj be a BIOS-ba és hagyd úgy a gépet. Ha így is újraindul / lefagy, akkor 98% a hardverhiba. Amíg a hardver nincs rendben, addig felesleges a szoftveren pörögnöd. Szerintem.

Nem az AMD ennek a baja, hanem hogy fos ASUS, gaming hülyeség, strapabírósága 0.

Mint írtam, most már fagyás, és újraindulás nincs, az kernel driver bug volt, több kernelkiadáson keresztül áthúzódva, 6.10-6.12-ig. A leállások viszont megvannak, de a mostani gyanúm szerint ez valami töltő-kábel-csatlakozó hiba. Majd meglátjuk, most egy pár napig csomagolok, hétvégén költözök, nem sokat tudok cseszekedni vele.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( hajbazer v | 2025. 03. 19., sze – 23:51 )

Kell neked mindig minden szarból a legújabbat, legfrissebbet használnod.

Aztán te fújsz a legacy rendszereket használókra, hogy szivatják magukat.

Ezzel nem az a baj, hogy nem legacy, hanem egy ASUS fos, szar a termék minősége, strapabírósága fizikailag. A hardver erejével, szoftveres támogatásával nem lenne baj, mert az patent. Csak fizikailag esik szét, első év végén, már kidöglött benne az aksi, most meg kikapcsolgat. Zsanér szétkúródása az az én hibám, bár ha nem szarakszik az aksi, akkor nem szedem szét soha, és a zsanérnek se lesz baja.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( trey | 2025. 03. 20., cs – 09:41 )

Szerkesztve: 2025. 03. 20., cs – 09:44

AMD-s? 🍿

trey @ gépház

AMD Ryzen 7 5700G CPU-val, a CPU-ra integrált videoval Fedora 42 magabiztos, stabil. Ennek a CPU-nak mobil változatával meglévő Acer Swift 3 gépem szintén Fedora 42-vel 6.14-rc7  kernellel teljesen stabil, azon dolgozom.

#worksforme
 

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

Igen. De van pont ebből a laptopból inteles is, és az is ugyanez a szétesős, meghalós szar. TUF, Military tufness, ez a reklámszlogen, Asus in search of incredible, közben meg minőségileg egy nagy fos. Értsd: szétesik, aksi döglik ki. Az AMD részével nagy baj nincs, az megy mint a szél, a kernelfejlesztők pár ciklusos hülyeségét, mint kitérőt leszámítva a driverrel se volt soha gond.

Ez van, nem volt jó vétel. Specifikációkra, szoftveres supportra nem rossz, de strapabíróságra egy fos sajnos, ezt nem lehetett tudni előre.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( khiraly | 2025. 03. 20., cs – 11:54 )

Ezt a Hardvert vásárolni tudni kell linuxhoz (2025) topikba írtam, de ide jobban passzol:

 

Hat nem tudom. En meg sose jartam igy, de most vettem par gepet, es linuxszal (kubuntu 24.04) kb. hetente egyszer elsotetul a monitor, es kb. 5-6sec mulva megjelenik egy commandline, hogy busybox initramfs).

En nem tudom, hogy a pekbe hagyja el magat. Windows 11 alatt meg sose jatszotta el. A gep egyebkent Asus PN53, AMD Ryzen 5 7535H 4.55 GHz processzor, NVMe SSD (WD black SN770) és 16GB memória (crucial ddr5 4800mhz).

 

Otletem sincs merre kene elindulnom a debugolasban. Annyira hirtelen es varatlanul csinalja. A homerseklettel sincs kulonosebben osszefuggesben amennyire latom.

Nesze neked AMD.

Tudom, nem nagy minta, egyedi eset, pebkac. De ez a pc platform egyre gagyibb.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( Ar0n v | 2025. 03. 21., p – 16:39 )

Hat ha kernel eszlel valamit azt valoszinuleg kikopi serial porton. this

( Raynes v | 2025. 03. 21., p – 20:22 )

Közben lett pozitív előrelépés. Úgy néz ki, hogy a tápkábel vagy tápcsatalakozó érintkezési hibája okozta a leállásokat. Most ideiglenesen szigszalaggal kirögzítettem a gép oldalára a töltőkábelt,, hogy ne mozduljon el, és már másfél napja egyszer se kapcsolt ki.

Amit viszont nem értek, hogy erre én gondoltam, és teszteltem úgy, hogy szándékosan a tápcsatinál mozgattam, forgattam, akkor nem tudtam reprodukálni, hogy kikapcsoljon. Magától meg kikapcsol.

Mindegy, ez csak ideiglenes megoldás, meg okulársra írom. Ez a gép mindenképp szanálva lesz a nagyon közeli jövőben.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

El tudom képzelni, hogy amikor mozgatod, akkor folyamatosan nekifeszíted a dugó fém csatlakozópontját a hüvelyéhez, ellenben ha magára hagyod, koncentrikusan az egyik, talán a belső pucuka alig csiklandozza az ellenoldali részt.

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