- Samsung Galaxy A54 - türelemjáték
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Vivo X200 Pro - a kétszázát!
- Milyen okostelefont vegyek?
- iPhone topik
- Poco X5 Pro - ránézésre jó
- Szinte játékpénzért megvehető a Honor Play 10C
- Google Pixel topik
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Azonnali navigációs kérdések órája
Hirdetés
-
Mobilarena
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
CPT.Pirk
Jómunkásember
válasz
Vasti74
#34630
üzenetére
Azt hiszem annyi bajod volt az Endeavourrel, hogy abban a telepítőben még megvolt a python-future csomag, ami már nem Python3 kompatibilis és fent sem kellene lennie a gépen. Ettől meg függőségi probléma miatt megakad a rendszerfrissítés amíg ezt a csomagot nem törölted le. Azóta ők is adtak ki új telepítőt.
Hogy ez konkrétan kinek volt a hibája azt nem tudom, a python világa nekem egy hatalmas katyvasz, de valszeg a többi arch környéki disztrón is találkoztál volna ezzel ott és akkor.
-
CPT.Pirk
Jómunkásember
válasz
Vasti74
#34579
üzenetére
Nézzük meg. Lehet a formátummal is gondja, abból is van vagy 6 féle amit tud a rendszer.
cat /proc/asound/cardsNálam ennek az 5-ös eleme a DAC-om:
5 [Audio ]: USB-Audio - USB2.0 High-Speed True HD AudioC-MEDIA Inc. USB2.0 High-Speed True HD Audio at usb-0000:15:00.0-1.1, high spee
És mikor zenét játszol le, akkor lehet ellenőrizni az aktuális beállításokat:cat /proc/asound/card5/pcm0p/sub0/hw_paramsaccess: MMAP_INTERLEAVEDformat: S32_LEsubformat: STDchannels: 2rate: 48000 (48000/1)period_size: 512buffer_size: 32768Itt nekem ez most nincs kimaxolva, az enyém az tudna 32bit / 384kHz-et.
-
CPT.Pirk
Jómunkásember
válasz
Vasti74
#34576
üzenetére
Azt nézném meg a DAC-nál, hogy nem-e vált fel időnként olyan bitszámra és mintavételezési frekvenciára, amit a DAC már nem kezel, mert alapból elég szűk tartományt tud csak használni.
Már fejből nem tudom hogyan volt, de anno én fájlban rögzítettem, hogy milyen beállítást használjon az én DAC-omnál, mert nem a lehető legjobbat használta alapból.
-
CPT.Pirk
Jómunkásember
válasz
Vasti74
#34475
üzenetére
Egy SMPlayert nézz még meg, mert a VLC-vel voltak mindenféle bajok az elmúlt időszakban. Azt nem tudom, hogy alapból engedélyezve van-e a HW gyorsítás... Ha ezt vagy a VLC-t terminálból indítod, akkor kiírják a HW gyorsítással kapcsolatos dolgokat is oda, csak mint érdekesség.
Az Arch alapok amúgy nem jelent semmi rosszat. Most már kb. 10 éve Arch leszármazott disztrókat használok, de ezeken sem használtam többet a terminált, mint bármelyik Ubuntu leszármazotton. Ez alól a Manjaro volt a kivétel, mert ott gyakran elcseszték a dolgokat a fejlesztők, de az nem az Arch alapok miatt van.
-
CPT.Pirk
Jómunkásember
válasz
Vasti74
#34461
üzenetére
A Kubuntuban régi a KDE... A KDE Neon meg inkább fejlesztők számára készül, mintsem normál hétköznapi használatra. Ez utóbbiban vannak limitációk is, pl. nem támogatják az zárt nVidia drivert, szóval ha nV kártyád van akkor nem ezt a disztrót javasolnám. Olvasd el a részleteket róla: [link]
Tulajdonképpen nem is tudom, hogy mi a jó választás Ubuntu vonalon, ha napi szinten is használható, de nem régi KDE-t szeretnél.
-
CPT.Pirk
Jómunkásember
válasz
Vasti74
#34454
üzenetére
Érdekes, hogy a 4K probléma lenne... Valamikor 2018-ban rákötöttem az asztalimra tesztképpen a 1440P monitorom mellé még egy ugyanolyat, valamint harmadiknak egy 4K TV-t is, de minden ment faszán. Mondjuk ez AMD hardveren történt és KDE-s disztrón, de nem igazán hiszem, hogy Intel cuccoknak a 4K problémát jelentene.
Majd írd meg, hogy mire jutottál. Deb vonalon pl. a PopOS!-t javaslom, még annak ellenére is, hogy Gnome-os disztró.
-
CPT.Pirk
Jómunkásember
válasz
Vasti74
#34450
üzenetére
Nem nagyon tudtunk neked segíteni, mert minden jónak néz ki. Előfordulhat hw specifikus dolog ami miatt tényleg érdemes legalább penről futtatva megnézni másik disztrókat, valamint írni a Mint fórumába is.
Én jó ideig együtt éltem egy hibával ami Manjaro alatt játék közben random fagyásokat okozott, miközben mások ugyanazt a kártya szériát gond nélkül használták... Odáig debuggoltuk a kernel/drm srácokkal, hogy valószínűleg nem volt jó a frekvencia - feszültség görbe (eltért a Windows alattitól) és terhelés alatt alulfeszelte a GPU-t a kernel, ami így instabillá vált. Végül nem vagyok benne biztos, hogy pontosan mi lett a megoldás, mert mikor a Manjaro KDE-t lecseréltem a tök hasonló EndeavourOS KDE-re, akkor ezek a problémák megszűntek.
Az is előfordulhat nálad, hogy egyszerűen van valami bug a Mint Cinnamonban lévő megjelenítő kódban... Régebben pl. küzdeni kellett Intel hardveren az egyszerűbb megjelenítőkkel, hogy ne legyen képtörés videólejátszás közben Intel VGA mellett.
-
#34367
CPT.Pirk
Jómunkásember
IstvánLászló
#34366
CPT.Pirk
Jómunkásember
válasz
IstvánLászló
#34366
üzenetére
Megerősítem. Ez a Manjaro JÓ verziója.
De tényleg, 2 év Manjaro használat alatt volt egy rakás lejárt GPG kulcs meg hasonló szívás, a majdnem ugyanaz Endeavournál meg semmi. Ráadásul nem irtották ki a VAAPI-t a mesából... -
#34358
CPT.Pirk
Jómunkásember
Roland861010
#34357
CPT.Pirk
Jómunkásember
válasz
Roland861010
#34357
üzenetére
Hülyeséget beszélnek. AMD hardveren telepíted a disztrót és megy. Még annyi munka sincs vele, mint Windows alatt.
-
CPT.Pirk
Jómunkásember
válasz
f_sanyee
#34350
üzenetére
Pedig előfordul, különösen ha W11-el van összehasonlítva a Linux, az OS overheadje bizony számít. Meg azt is láttuk már, hogy pl. az AMD oldalon a nyílt driver a mesa-val képes lenyomni a zárt AMD drivert...
#34354 Roland861010: mint gamer mondom, ez nem így van. Ráadásul nVidiával annyira nem sima a helyzet sajnos.
-
-
CPT.Pirk
Jómunkásember
Van egy működő samba megosztásom helyi hálón, win alatt explorerből rá lehet menni a \\192.168... módon.
Viszont azt meg lehet csinálni, hogy a Network alatt látszódjon a megosztás, mint régen? Mindenféle változás volt az SMB protokollok terén, a google találatok meg egymásnak ellentmondanak, vagy már nem működnek a változások miatt.
-
-
CPT.Pirk
Jómunkásember
válasz
bambano
#34276
üzenetére
Igen... Tudtam róla, hogy megjelent pár bad sector és már tervben is volt a cseréje... Aztán most hirtelen 10x annyi bad sector lett meg 4000 gyenge és azt mondja a hd sentinel, hogy még van 4 nap hátra az életéből...
Mondjuk tök jó, hogy kifejezetten 24/7-es üzemre való, kamerarendszerhez kitalált hdd-t használtam és alig 4 évet bírt ki...
májkimiki: lehet sosem végeznék vele. Még a fájlkezelőben a mappák között navigálás is fájdalmasan lassú ezen a cuccon. Most meg egy svn mappát próbálok menteni, ami rengeteg apró fájlból áll... Asszem egész éjjel ezen fog dolgozni.
-
CPT.Pirk
Jómunkásember
Erősen bad sectoros, de még működő HDD-ről mivel tudnék adatot menteni? A csak simán olvasás az nem igazán működik. Ext4 a partíció. Valami olyan kellene, ami feltérképezi és mindent kimásol egy mappába.
Egy teljes fsck már végigment a lemezen, de csodát nem tett.
-
CPT.Pirk
Jómunkásember
válasz
bambano
#34232
üzenetére
De kint van, ahogy a gépeink is, onnan backupolja a OneDrive / sharepoint megosztásainkat. Már csak ezért is frissíteni kell időnként legalább a klienst, mert szokott változni az OneDrive API.
Ráadásul az svn szervert is elérhetővé kellett tenni kívülről, sajnos a legfőbb munka programunk egy bug miatt csak ilyen formában tud svn szervert kezelni, majd ha egyszer veszünk új verziót akkor ez megszűnhet, csak hát méregdrága a program...
A net a cégnél meg ilyen telephelyi net, ami megoszlik több cég között... Szóval semmi sem ideális, én meg nem vagyok IT-s, nincs is IT nálunk.
Illetve van, én mert más nincs... Érted. 
-
CPT.Pirk
Jómunkásember
válasz
bambano
#34230
üzenetére
Megjavítani nem akarom ami működik, de azért egy LTS Uborkától szokatlan, hogy ne lehetne pár hetente frissíteni hiba nélkül, miközben itthon meg már több éve Arch alapú pörgő disztrókat használok és minden frankó...
Amúgy igazából idő kellene, hogy átgondoljam ezt az egész backup szerver témát, de annyi meló van, hogy "jóvanezígy". Most csak egy összetákolt régi gép egy vacakoló szünetmentesre kötve egy "garázscégben".
-
CPT.Pirk
Jómunkásember
válasz
urandom0
#34228
üzenetére
Van egy b. drága célprogramunk, ami kezelne SVN szervert fájlban és akkor az is mehetne OneDrive-on, ahogy a GIT-et is használjuk, de a mi verziónkban ez bugos, nem lehet használni. Viszont helyi hálón meg kezeli az SVN-t, így azzal dolgozunk. Sajnos bazi drága lenne új verzióra frissíteni a proginkból...
Mondjuk az OneDrive önmagában is egy csoda. Csoda, hogy működik...
-
#34224
CPT.Pirk
Jómunkásember
lionhearted
#34223
CPT.Pirk
Jómunkásember
válasz
lionhearted
#34223
üzenetére
Jaaa hát őőő izé peeeersze
Pici cég vagyunk, igazából ez a backup rsync-es backupja olyan esetekre, ha pl ilyen titkosító valami sikerrel jár és a OneDrive-on lévő dolgaink is elvesznének. Igaz azóta SVN szerver is lett belőle, de az meg kényszerből. Na annak mondjuk nincs backupja... De majd egyszer! Nem próbáltam még a live patchinget, de a probléma a boot során jött elő. Ha a live patch után működik is az új kernel, egy következő rebootnál megint bele fog halni, nem?
-
CPT.Pirk
Jómunkásember
Az a gond, hogy ez a helyi svn és a onedrive backup szerverünk. Ha most felrakom az új kernelt és megint gond van, akkor egy fél órám rámegy a helyreállításra, de akár még adatvesztésem is lehet. Előbb le kéne menteni valahová majdnem 2TB adatot, hogy ezzel próbálkozzak.
Melegedés gond nincs. Mondjuk a benne lévő hardver azzal a régi bulldozer procival nem is igen tud fűteni.
Lehet inkább megvárom mire kijön a -38 utáni kernel, aztán azzal próbálkozok.
Arra sem találtam megoldást, hogy miért szaggat az asztal használata, mióta 24.04-re frissítettem, miközben egyébként van 3D gyorsítás is. Megy a repülő kenyérpirítós képernyővédő, de darabos a mozgás benne... Lehet még korai volt 24.04 LTS-re frissíteni.
-
CPT.Pirk
Jómunkásember
Lubuntu 24.04 LTS-en kijött a napokban a 6.8.0-38 kernel, most frissítettem de elakadt vele a boot, azt írta hardver hibák vannak a tárhelynek használt hdd-men és nem is tudta felcsatolni az egy szem Ext-4 partíciót, de még egy reboot parancsot sem tudtam végrehajtani recovery konzolból mert rögtön írogatta ki a hibaüzeneteket.
Az egyel korábbi -36 kernellel be tudtam bootolni, eltávolítottam az újat, majd futtattam hibakeresést ami helyre is állított egy csomó hibát azon a partíción és most újra működik a gép.
A gép egy régi AMD-s gép, de eddig az összes Uborka kernel járt rajta a 4. valamitől kezdve, semmi ilyen gondja nem volt soha és a hdd smart adatai sem mutatnak hibát.Próbáltam rákeresni erre a problémára a kernel kapcsán, de nem találtam semmi relevánst.
-
#34188
CPT.Pirk
Jómunkásember
lionhearted
#34187
CPT.Pirk
Jómunkásember
válasz
lionhearted
#34187
üzenetére
Nem, Lubuntuban az még csak opcionális, még nincs kész.
-
CPT.Pirk
Jómunkásember
Van egy régebbi, AMD FX-es gépem integrált vga-val, ami szervernek van beállítva, de van rajta GUI is. Lubuntu 20.04 és lefrissítve 22.04-re az is frankón ment rajta. Most frissítve a 24.04-re az is frankó, de a grafika darabos lett, miközben amúgy megy a 3D.
Ősi AMD HW: https://pastebin.com/g9nJkz7D
-
CPT.Pirk
Jómunkásember
válasz
sh4d0w
#33831
üzenetére
Az nVidia developre repója hozzá lett adva, mert cuda specifikus lib-ek nincsenek meg a zárt driverben. De most nem tudom mit tudok kezdeni ezzel a helyzettel, hogy a csomag verzió nevek nem stimmelnek össze:
535.154.05-0ubuntu1-vs- 535.154.05-0ubuntu0.22.04.1
Eddig sem értettem az Ubuntu csomag elnevezési szisztémáját...
-
CPT.Pirk
Jómunkásember
Ubuntu 22.04 célgép, cuda-t használ. Azt hiszem két csomagban is ugyanaz a fájl van és így felülírási gond van.
És itt van róla megerősített bugreport, megoldás nélkül: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-535/+bug/2026349
Ilyenkor mit lehet csinálni?
-
CPT.Pirk
Jómunkásember
válasz
ubyegon2
#33821
üzenetére
Nem értek egyet. Mikor a satás SSD-meg cseréltem az akkor jónak számító, 3000-es olvasást tudó SSD-re, az nem csak érezhető, de mérhető előnyt is hozott a betöltési időkben, minden fürgébb lett. Mindezt átklónozott, nem frissen felrakott rendszerrel.
Most elmentem a maximumra, az említett 3000-es SSD-t cseréltem 7000 felett olvasni tudóra ami ment be a PCIe gen4-es foglalatba, mert ha már úgy is kellett a 2TB, akkor legyen jó és időtálló is a cucc. Nyilván itt már nem volt érezhető ugrás, mert az előző is bazi gyors volt.
Ráadásul ezek a dolgok nyilván függnek attól is, hogy jóféle procit raksz-e a gépbe, vagy olyat amin elfut az Excell... Mikor anno egy régi, ráadásul abból is low-end FM2-es AMD-s gépbe migráltam át a Windowst egy HDD-ről SSD-re, az szinte semmit nem gyorsult mert a proci volt a szűk keresztmetszet...
-
CPT.Pirk
Jómunkásember
Vagy problémát okozott, hogy a telepítés idején még használtam curve optimizert, ami miatt nem minden mag volt minden körülmények között volt stabil a prociban, de ezt akkor még nem tudtam.
Ugyanekkor telepítettem egy 95%-ban azonos gépre ugyanezt a disztrót és ott sosem volt ez a kernel param probléma. -
CPT.Pirk
Jómunkásember
Boot során látok egy ilyet:
Couldn't write '' to 'vm/min_free_kbytes': Invalid argument
Azt kibontva ezt látom:systemctl status systemd-sysctl.service× systemd-sysctl.service - Apply Kernel VariablesLoaded: loaded (/usr/lib/systemd/system/systemd-sysctl.service; static)Active: failed (Result: exit-code) since Fri 2024-01-26 17:40:21 CET; 15min agoDocs: man:systemd-sysctl.service(8)man:sysctl.d(5)Process: 668 ExecStart=/usr/lib/systemd/systemd-sysctl (code=exited, status=1/FAILURE)Main PID: 668 (code=exited, status=1/FAILURE)CPU: 5msStarting Apply Kernel Variables...Couldn't write '' to 'vm/min_free_kbytes': Invalid argumentsystemd-sysctl.service: Main process exited, code=exited, status=1/FAILUREsystemd-sysctl.service: Failed with result 'exit-code'.systemd[1]: Failed to start Apply Kernel Variables.Hogyan tudom kideríteni, hogy mi a gond? Üres értéket akar beírni változóba?
Magának a változónak az értéke most is megvan a rendszerben: vm.min_free_kbytes = 67584Nincs maxperfwiz vagy bármi, ami belenyúlna ebbe. Tulajdonképpen már hónapok óta megvan ez a dolog, csak most néztem utána...
-
-
CPT.Pirk
Jómunkásember
Inkább itt kérdezek rá,
Ubuntu 22.04 alatt próbálok parancsikont gyártani... Van egy deeplabcut célprogi ami állatok mozgását elemzi AI-val videó alapján, és az anaconda környezet alá telepített python 3.8-al működik. Ez a script:#!/bin/basheval "$(conda shell.bash hook)"conda activate DLCpython -m deeplabcutÉs ez fut is terminálból, elindul a progi. Viszont ha csinálok rá egy DLC_Start.desktop fájlt, hogy a gui-ról is el lehessen indítani, akkor persze nem találja se a conda-t, se a pythont.
Ha a fájlba beírom ezeknek a pontos elérését, akkor meg a python nem találja a deeplabcut modult. Itt leakadtam...Hogy a csudába kéne ezt megcsinálni? Az egész DLC progi egy tákolmány, csak python 3.8 alatt telepíthető, a rendszerben lévő 3.11 nem jó neki, ezért kell ez az anaconda környezet. Van belőle ugyan dockeres verzió, de az meg túl régi csomagokkal dogolzik a vga kártya használatához és amúgy is csak béta.
-
#33408
CPT.Pirk
Jómunkásember
Dr.FantastiK
#33406
CPT.Pirk
Jómunkásember
válasz
Dr.FantastiK
#33406
üzenetére
Melyik disztrót nézted meg? A csomagverziók miatt kérdezem. Ha lenne ilyen 10 bites monitorom, akkor megnézném AMD kártyával mi a helyzet.
sh4d0w: jajj de az utóbbi 3 csatornára van.
-
#33401
CPT.Pirk
Jómunkásember
Dr.FantastiK
#33400
CPT.Pirk
Jómunkásember
válasz
Dr.FantastiK
#33400
üzenetére
2022 februári hír, hogy:
"- Support for 30-bit color in the Plasma X11 session, starting with Plasma 5.24." [link]Aztán idén elkezdték a HDR-t implementálni Linux szerte, volt áprilisban RedHat hackfeszt a témában, meg a Valve már játékok alatt is működő HDR-t produkált a Steam Deck-en, szóval biztosan nem ott tart a dolog, ahol 2 éve, de ki kellene próbálnod.
nVidiánál meg elkezdtek érdemben nyílt drivert fejleszteni (nvk), így idővel talán már náluk sem fog kelleni a gyári driver, de az még ki tudja mikor kerül be a mesa-ba.
-
-
CPT.Pirk
Jómunkásember
Saját fejlesztésű termék teszter, én írom Lazarus alatt. Pár kB-os log fájlok gyűlnek a műszakok során, míg nem valaki x időnként lementi a gépről. Ennek jobb módja SQL adatbázisba (is) feltöltés lenne és régebben így is működött, de most erre nincs lehetőség.
ivana: még nem használtam brtfs-t de ismerős amit mondasz, ránézek.
gregory91: nem, azt nem terveztem.
-
CPT.Pirk
Jómunkásember
Ti hogyan csinálnátok meg egy, a termelésben használt Linuxos PC-t, ami egy célprogramot futtat?
Tegyük fel, hogy szünetmentes táp ellenére is előfordulhat, hogy kihúzzák a tápot vagy egyszerűen nem szabályosan állítják le, csak kinyomják...Az az elképzelésem, hogy a root partíciót csak olvashatóra csatolnám fel, a célprogram pedig egy második partíción futna és oda is dolgozna, ő írogat kis szöveges fájlokat egy mappába.
Eredetileg Raspberry-t használtam volna erre ahol meg tudtam volna oldani hardverből a leállítás elindítását tápelvétel esetén is, lett volna kis áthidaló aksi / szuper kapacitás, de a célprogramom egyik részét nem tudom ARM procira portolni, így kénytelen vagyok rendes PC-t használni.
-
CPT.Pirk
Jómunkásember
Firefox alatt bizonyos videós oldalak hangja torz, pl. a southpark hivatalos oldalá is, de közben a Youtube meg príma. [link] Ugyanakkor Falkon böngészővel nincs egyáltalán baj. Valaki találkozott ilyennel?
Ráadásul két tök hasonló gépem van, azonos OS-el és csak az egyik csinálja. Mondjuk a hangkártya eltér a két gében. EndeavourOS KDE.
-
-
CPT.Pirk
Jómunkásember
válasz
urandom0
#32973
üzenetére
Az előző 2 évben Manjaro-t használtam, ami ebből a szempontból elég hasonló. Ott 2x volt olyan, hogy valamit kézzel kellett csinálni, de az is csak 1-2 parancs kiadása volt és leírták, hogy mit kell csinálni. Az más kérdés, hogy pár alkalommal elcseszték a tanusítványok megújítását így nem tudtál frissíteni 1-2 napig, de ez a Manjaro saját problémája volt...
Az XFCE-t én mondjuk nem kedvelem. Ahhoz képest amit nyújt, sokat fogyaszt és ez régebben nem így volt. Mindeközben pl. video tearing meg hasonló gondok előfordulnak vele, az meg komolyabb asztali környezetek alatt nem jellemző. xfce-ből 4.18-nál tartunk.
Amúgy nyilván ugyannak a kernelnek újabb és újabb build-jeit kapjuk meg pár naponta. Most éppen a 6.1.11-nél járunk. Ami nekem nagyon fontos, az a mindig friss mesa, mert aktívan játszok Linux alatt. Abból most 22.3.4-nél tartunk.
arcoskönyv: Ahh, UD a kedvencem. - "you are a man of culture as well"
-
-
CPT.Pirk
Jómunkásember
válasz
urandom0
#32967
üzenetére
Igen, a nevét leírni továbbra is kihívás.
Lassan két és fél hónapja használom két gépen is, de minden fasza. Gyakran jönnek a frissítések, de minden klaffol. Egy-két grafikus megoldás hiányzik a Manjaroból, de csak megszokás miatt.
Egy dolog szivatott kicsit, az alapból aktív firewalld kezelőfelülete eléggé ostoba, csak több nap után jöttem rá, hogyan kell állandóra kiengedni a netre a KDE Connectet, mert alapból tiltotta.
Jah meg izé, fel kellett rakni az ssh-tools csomagot, hogy tudjak ssh-n belépni egy másik gépre. Oké, elég slim disztró, de ez meglepett.
Egyébként gyors, és csak simán működik. Valszeg hosszú távra marad nálam ez a disztró.
-
CPT.Pirk
Jómunkásember
válasz
vargalex
#32937
üzenetére
Hmm, mióta szilveszterkor legyalultam a Manjaro-t és átmentem EndeavourOS-re, azóta nem vizsgáltam meg a szitut. Azt nézem, hogy by default, ezeket az értékeket hozza a rendszer:
vm.dirty_background_bytes = 0vm.dirty_background_ratio = 3vm.dirty_bytes = 0vm.dirty_expire_centisecs = 3000vm.dirty_ratio = 3vm.dirty_writeback_centisecs = 1500vm.dirtytime_expire_seconds = 43200De hát ezek meg azok az értékek, amiket a maxperfwiz is kiszámolt korábban.
A telepítés után anno reflexből lenyomtam a maxperfwizt, nem is figyeltem, hogy csak a swapinnest meg a vfs_cache_pressure állította át.Csináltam pár másolási tesztet, de nem láttam érdemi különbséget az között, ha ment ahogy alapból van, meg ha szándékosan elrontottam a Manjaro alatti default értékek visszaállításával. Mindeközben tavaly Manjaro alatt meg ég és föld volt a különbség.
Nem tudom mi történt, de mintha valaki a telepítés részévé tette volna EndeavourOS alatt a vm.dirty beállítások aktualizálását a ram mennyiségének megfelelően.
-
CPT.Pirk
Jómunkásember
válasz
vargalex
#32934
üzenetére
Érdekes. Minden "gyárin" van? Még az Arch Wiki is írja [link] , hogy nagyobb memória mellett hozzá kellene nyúlni legalább a wm.dirty_ratio értékéhez mert úgy túl sokat foglal be és kvázi feltorlódás alakul ki másolás közben.
bambano: neked belefér, oké. Kezdjük ott, hogy te egyáltalán tudsz ennek a szkriptnek a létezéséről. Az a baj, hogy ilyen apróságok okoznak bosszúságot a mindennapi Linux használatban, amiből utána az csapódik le, hogy "szaralinux".
-
CPT.Pirk
Jómunkásember
válasz
bambano
#32930
üzenetére
Ezek szerint nem fogalmaztam egyértelműen. Nem az egész szkriptre gondoltam, hanem kifejezetten csak azokra a részeire, amik lehetővé teszik, hogy ki tudjak írni egy nagyobb fájlt egy penre, vagy másik partícióra emberi idő alatt. Vagyis ami figyelembe veszi memória mennyiségét a gépben, ráadásul véleményem szerint minden induláskor le kéne futnia a háttérben, ha megváltozik a ram mennyisége. De tőlem aztán bármi lehet a megoldás, ami így működik, csak legyen valami.
És ez a másolás dolog bizony általános probléma, amire remélem nem azt a választ kapom, hogy "akkor használj Windowst". Annyira általános, hogy tele van a google találatokkal ha rákeresel.
-
CPT.Pirk
Jómunkásember
válasz
f_sanyee
#32924
üzenetére
Igen, elég egyszer lefuttatni, de ahhoz meg az kell, hogy egyáltalán tudjál róla, hogy létezik ilyen, én is csak pár hete találtam meg... Nem láttam még negatív véleményt róla, itt is kipróbáltattam pár emberrel már de mindenkinél "csodát tett".
Nem rég vettem 128GB-os USB3-as pent. Ki kellett írnom egy nagy fájlt rá, az írási sebessége 5 perc után drasztikusan esett aztán fél órával később már nem érte el az 1 MB/s-ot sem. Berágtam, mert kellett volna mennem a dolgomra de basszus csak nem bírja megírni azt a fájlt... Aztán egyszer csak kiadta a google erre a problémára a találatot (a találatok alapján sok-sok éve létezik ez a probléma), hogy a manjaro fórumban van egy halott bejegyzés erről a cuccról... Na mondom uccu... Lefuttattam, azóta pont úgy tudom írni a pent, mint Windows alatt.
Látva, hogy mihez nyúl hozzá a szkript (most az udev részét nem nézve), szerintem ezzel nem lehet rosszul járni. El kellene indítani erről a beszélgetést, csak lövésem nincs róla merre. Egyébként desktop vonalra gondoltam, ahol ma már tök általános a 16GB vagy több ram és ez okozza a problémát.
-
CPT.Pirk
Jómunkásember
Amúgy, ti mit tudtok arról, hogy a maxperfwiz-t meddig kell még kézzel futtatni hozzá egy desktop disztrón, hogy egy mai gépen (8 GB vagy több ram mellett) emberi sebességgel lehessen fájlokat mozgatni partíciók között vagy pendrivera?
Vagy hol van ennek fóruma, ahol fel lehetne ezt vetni, hogy ilyesmit be kellene építeni valakinek valahová... A default értékek amikkel települ egy mai disztró azok egyszerűen nem jók sok ram mellett és csak frusztrációt okoznak.
-
CPT.Pirk
Jómunkásember
Korábban írtam, hogy gond van az RX5600XT radeonok működési feszültségeivel, hogy egy kicsit alulfeszeli a kártyát a kernel ami ettől instabil lesz és akkor jön a ring gfx timeout összeomlás...
Miután kiderült az alulfeszelés ténye, gondoltam, hogy ez a probléma forrása de szilveszterkor újraraktam a két érintett gépet és bár a lekérdezett értékek szerint továbbra is alulfeszelik ezeket a kártyákat, de mégsem lehet összeomlasztani GPU-t, mindkét gépem stabil mint a kő.
Ha fogok egy régebbi live ISO-t, azzal bebootolva a gépet pár perc alatt ki tudom nyírni a GPU drivert, csak rá kell engedni a GpuTest progi rgb háromszögét és már jön is a crash 1-2 perc alatt. Ugyanennek a live rendszerne újabb kiadásával ez már nincs meg, stabil a gép. Ahogy több más friss live disztró esetén is.
Arra jutottam, hogy valamikor 2 éve mikor ezeket a gépeket telepítettem, akkor történt valami, ami megmaradt... Ugyanakkor ezek a telepítések Manjaro-k voltak, ami eléggé rolling disztrók, nem tudom hogy tud bármi is megmaradni hosszabb távon... Az egyik gépen egy régebbi telepítésű Mint is van tartaléknak, az alatt is megvolt a driver összeomlás, pedig az is rendszeresen frissítve lett, mindeközben friss Mint ISO-val stabil a gép.
Szóval a szilveszteri EndeavourOS telepítés óta mindkét gépem stabil mint a kő... Ugyanakkor a számok alapján továbbra is egy kicsit alulfeszeli a GPU-kat a kernel.
Ha valakinek van Navi10-es Radeonja (RX5600, 5700 kártyák) és becsatlakozna a vizsgálódásba, akkor itt tud: [link] - az utolsó 1 hónap hozzászólásait nézze meg.
-
CPT.Pirk
Jómunkásember
Nálatok is ez volt az eredeti állapot?
vm.dirty_background_bytes = 0vm.dirty_background_ratio = 10vm.dirty_bytes = 0vm.dirty_expire_centisecs = 1500vm.dirty_ratio = 20vm.dirty_writeback_centisecs = 1500vm.dirtytime_expire_seconds = 43200
Főleg a dirty_ratio a probléma a ma megszokott 16..32GB ram mellett. -
CPT.Pirk
Jómunkásember
https://gitlab.com/cscs/maxperfwiz/
Arch és Manajro alatt szükséges ez a szkript, ha nagyobb fájlokat szeretnél másolni emberi idő alatt pendrivera, vagy partíciók között.
Ezeket az értékeket variálja, egy részét a gépben lévő ram mennyísége alapján, ezek már a frissített értékek nálam:
vm.vfs_cache_pressure=75vm.dirty_ratio=3vm.dirty_background_ratio=3vm.dirty_expire_centisecs=3000vm.dirty_writeback_centisecs=1500vm.min_free_kbytes=118812Más disztróknál mi a helyzet?
Konkrétan akkor akadtam rá erre, mikor elkezdtem nyomozni, hogy egy 70GB-os fájl másolási sebessége pár perc után miért esett le 1MB/s alá. A szkript futtatása óta meg gyönyörűen tudok másolni ekkora fájlokat is. -
CPT.Pirk
Jómunkásember
Korábban párszor írtam a játék közben meghaló AMD driverről, mikor a gpu próbálja magát resetelni de belehal és lehet a gépet újraindítani...
Na azóta megleltem a kapcsolódó freedesktop.org gitlab oldalt ahol viszont azt látom, hogy gyakorlatilag minden Vega vagy újabb AMD hardver alatt is jelentkezik a probléma, de még akkor is elő tud fordulni, ha csak böngészel a gépen (ezt én is megerősítem). 3 hete én is csináltam itt egy hibajegyet, de sok minden nem történt. Ahogy látom, a többi hasonló hibajegyben sem.
Megpróbáltam kideríteni, hogy egyáltalán foglalkozik-e az AMD vagy bárki ezzel a problémával, de zátonyra futok. Az okótberi amd-gfx levél listát végignézve nem. Előző hónapokat nem álltam neki végigtúrni, mert ez is túl sok szöveg volt. Az sem világos, hogy mikor mi kerül be a kernelbe, a kernel.org-on a changelog az egy bazi nagy wall-of-text amivel nem tudom mit lehet kezdeni...
Abban biztos vagyok, hogy nagyjából kernelről kernelre javul a helyzet, mert tesztelgetve korábbi kerneleket jóval rosszabb volt a helyzet ezzel a gpu reset problémával, de nem tudom, hogy hol tartunk vagy merre haladunk és ez frusztráló.
Nem tudom hol lehetne még nyomozni ezekben a kérdésekben.
-
CPT.Pirk
Jómunkásember
-
-
CPT.Pirk
Jómunkásember
amdgpu 0000:08:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0011 address=0x2b17c0000 flags=0x0000][drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out![drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out![drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring comp_1.2.0 timeout, signaled seq=11613, emitted seq=11614[drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process GameThread pid 12775 thread GameThread pid 12824amdgpu 0000:08:00.0: amdgpu: GPU reset begin!amdgpu 0000:08:00.0: amdgpu: failed to suspend display audioamdgpu 0000:08:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring kiq_2.1.0 test failed (-110)[drm:gfx_v10_0_hw_fini [amdgpu]] *ERROR* KCQ disable failed[drm] free PSP TMR bufferCPU: 14 PID: 9847 Comm: kworker/u64:0 Not tainted 5.19.14-1-MANJARO #1 bb381310e9735642d17ffd4df21276ec37bc90d1Hardware name: ASUS System Product Name/TUF GAMING B550M-PLUS, BIOS 2803 04/27/2022Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched]Call Trace:<TASK>dump_stack_lvl+0x48/0x60amdgpu_do_asic_reset+0x2a/0x45d [amdgpu d7f739a1ec9af0997b0d6a34c65113fb23857f42]amdgpu_device_gpu_recover_imp.cold+0x492/0x8ea [amdgpu d7f739a1ec9af0997b0d6a34c65113fb23857f42]amdgpu_job_timedout+0x18f/0x1c0 [amdgpu d7f739a1ec9af0997b0d6a34c65113fb23857f42]drm_sched_job_timedout+0x7a/0x110 [gpu_sched 8e6237b7f67240ecaa97abe8a787d3c1d71c0d32]process_one_work+0x1c7/0x380worker_thread+0x51/0x390? rescuer_thread+0x3b0/0x3b0kthread+0xde/0x110? kthread_complete_and_exit+0x20/0x20ret_from_fork+0x22/0x30</TASK>amdgpu 0000:08:00.0: amdgpu: BACO resetamdgpu 0000:08:00.0: amdgpu: GPU reset succeeded, trying to resume[drm] PCIE GART of 512M enabled (table at 0x0000008000E10000).[drm] VRAM is lost due to GPU reset![drm] PSP is resuming...[drm] reserve 0x900000 from 0x817e600000 for PSP TMRamdgpu 0000:08:00.0: amdgpu: RAS: optional ras ta ucode is not availableamdgpu 0000:08:00.0: amdgpu: RAP: optional rap ta ucode is not availableamdgpu 0000:08:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not availableamdgpu 0000:08:00.0: amdgpu: SMU is resuming...amdgpu 0000:08:00.0: amdgpu: use vbios provided pptableamdgpu 0000:08:00.0: amdgpu: smc_dpm_info table revision(format.content): 4.5amdgpu 0000:08:00.0: amdgpu: SMU is resumed successfully![drm] kiq ring mec 2 pipe 1 q 0[drm] VCN decode and encode initialized successfully(under DPG Mode).[drm] JPEG decode initialized successfully.amdgpu 0000:08:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0aamdgpu 0000:08:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0amdgpu 0000:08:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0amdgpu 0000:08:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0amdgpu 0000:08:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0amdgpu 0000:08:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0amdgpu 0000:08:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0amdgpu 0000:08:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0amdgpu 0000:08:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0amdgpu 0000:08:00.0: amdgpu: ring kiq_2.1.0 uses VM inv eng 11 on hub 0amdgpu 0000:08:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0amdgpu 0000:08:00.0: amdgpu: ring sdma1 uses VM inv eng 13 on hub 0amdgpu 0000:08:00.0: amdgpu: ring vcn_dec uses VM inv eng 0 on hub 1amdgpu 0000:08:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 1 on hub 1amdgpu 0000:08:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 4 on hub 1amdgpu 0000:08:00.0: amdgpu: ring jpeg_dec uses VM inv eng 5 on hub 1amdgpu 0000:08:00.0: amdgpu: recover vram bo from shadow startamdgpu 0000:08:00.0: amdgpu: recover vram bo from shadow done[drm] Skip scheduling IBs![drm] Skip scheduling IBs!amdgpu 0000:08:00.0: amdgpu: GPU reset(1) succeeded![drm] Skip scheduling IBs![drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!Van nekem ez a problémám, mikor egyszer csak minden előjel nélkül meghal a GPU (leginkább játék alatt), megpróbálja resetelni magát de nem jut vele sokra és kénytelen vagyok újraindítani a gépet... Írtam már róla korábban, nem tudom kihez kellene fordulnom ezzel.
Azóta egy 2. gépen is reprodukáltam ezt a problémát (ez a dmesg kimenet is onnan van), ugyanolyan, de nem ugyanazzal a Sapphire Pulse 5600XT kártyával. Szóval a számítógép egyéb hardverelemeit szerintem ki lehet zárni a képből, ez valami szoftveres dolog, ami az 5600XT-t érinti.
Ebben a gépben egy két generációval öregebb RX570 vga hibátlanul működött éveken át. A furcsa az, hogy mindkettő vga-t ugyanaz az AMDGPU driver hajtja.*Manjaro KDE, 5.19-es kernel.
-
CPT.Pirk
Jómunkásember
Korábban írtam róla, hogy van ez a problémám játékok alatt, mikor egyszer csak totál random meghal valami és ekkor történik egy GPU Reset, ami aztán nem képes helyreállítani a működést.
Most is megtörtént, de most egy komplett stacktrace is bekerült a logba, ilyen eddig nem volt. Hová érdemes feltöltenem, hogy esetleg olyan is lássa, aki írja az amdgpu kernel drivert? Ezzel a loggal talán tudna valamit kezdeni...
-
CPT.Pirk
Jómunkásember
A tegnapi hír a natív .NEt 6-ról Ubuntura az mit jelent egy átlaguser szempontjából?
https://www.phoronix.com/news/Ubuntu-22.04-LTS-dotNET-6 -
CPT.Pirk
Jómunkásember
válasz
CPT.Pirk
#32259
üzenetére
Most először, a bekapcsolás után röviddel, 2D képtartalom mellett is meghalt a... ?vga driver?
Arra mentem be a szobába, hogy pepita képhiba virít a képernyőn fél perccel a boot után. A releváns részekről tettem fel pastebinre: [link]
Röviden, kezdődött egy valamivel:júl 19 17:30:43 kepsz-pc kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=1309, emitted seq=1311 júl 19 17:30:43 kepsz-pc kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process firefox pid 1482 thread firefox:cs0 pid 1660Ekkor elindul egy gpu reset, de azt hiszem belehalt a reset folyamatba. Aztán pedig újra és újra megpróbálja, de egyszer sem sikerül neki a reset. A pastebin végét levágtam, mert csak ismétlődés volt benne még hosszan.
Van valami ötletetek? Vagy h. kinek kellene jeleznem ezt a gondot?
-
CPT.Pirk
Jómunkásember
válasz
bambano
#32263
üzenetére
Másfél órát ment a gép porszívó módban, procit minden szálon a stress-ng -vel, gpu-t meg a furmarkkal terheltem le. A problémát nem tudtam előidézni, de a hőmérsékletek se szálltak el. Szóval szerintem a tápot kizárhatjuk.
Szóval szerintem szoftveres a probléma, csak nem tudom mit kezdjek vele.
-
-
CPT.Pirk
Jómunkásember
válasz
bambano
#32263
üzenetére
Ez mondjuk igaz, az áramfelvétel ilyen hardvernél tüskés jellegű magas csúcsokkal, amiket ki kell tudnia szolgálni a táp kimeneti kondijainak és ez nem látszik a pusztán a wattszámból. Na majd utánajárok ennek.
Linux alatt van olyan komoly gpu terhelő progi, mint mondjuk a Furmark szőrös fánkja Windows alatt?
Így kapásból a Unigine benchmarkjai vannak meg nekem, de az nem stressz teszt. -
CPT.Pirk
Jómunkásember
válasz
bambano
#32260
üzenetére
A táp bírja, kiszolgálja az 5800X procimat és egyszerre a vga-t is. Illetve ebben nem vagyok biztos, hogy mindkettőt egyszerre 100%-on megjárattam-e, ezt még kipróbálom. Külön-külön mindkettőt meghajtottam már 100%-on hosszabb ideig is.
Úgy egyébként nem rég cseréltem alaplapot és vele együtt procit is 3600X-ről 5800X-re, de nem volt kihatása a problémára.
Abból gondolom a problémát szoftveresnek, hogy ezen a gépen W10 alatt teljesen stabil a kártya.
-
CPT.Pirk
Jómunkásember
Aktívan játszok Linux alatt, van 2 gépem AMD vga-val és mesa-val használom őket, az oprendszer mindkettőn Manjaro KDE.
Az egyiken minden frankó, régebbi RX570 vga van benne.
A másikban is majdnem minden frankó, 2 generációval modernebb RX5600 XT van benne. Viszont mióta csak megvan ez a kártya, ez már több mint 1 éve, játék közben random előfordul, hogy kimerevedik a kép, aztán átmegy fekete képernyőbe, majd visszajön az utolsó képkocka, de úgy mintha ram hibás lenne a kártya. (nem az, alaposan kiteszteltem)"ERROR* Waiting for fences timed out!"Ilyenkor annyit tudok tenni, hogy átlépek konzolra és ott újraindítom a gépet. Aztán jellemzően tudok játszani, mintha mi sem történt volna. Ilyenkor ez zajlik le: dmesg
Szóval valamitől meghal a vga és csinálni próbál egy gpu resetet, de belehal. Ez a gpu reset képesség egy relatíve új dolog a kernelben, de a leírt hiba már akkor is volt, mikor még nem volt a kernelben ez a képesség.
Ugyanezzel a problémával mások is küzdenek: [link] [link] [link] de h. hová kellene fordulnom ezzel, azt nem tudom.
Az eltelt kb. másfél év alatt volt olyan kernel - mesa - amd firmware kombináció, amivel nem jött elő a hiba és akkor pár hétig jó volt, talán kétszer is. Játéktól független, mindegyik játékom alatt találkoztam vele a Cyberpunktól az STO-ig.
Legalább is Debian stable mellett, ha jól nézem még nem jutottak el a 6-os KDE-ig sem.
Most hol tart a sztori? Megnéztél végül valami másik disztrót KDE-vel?
Illetve van, én mert más nincs... Érted. 
A telepítés után anno reflexből lenyomtam a maxperfwizt, nem is figyeltem, hogy csak a swapinnest meg a vfs_cache_pressure állította át.
Új hozzászólás Aktív témák
Hirdetés
- Samsung Galaxy A54 - türelemjáték
- Vezeték nélküli fejhallgatók
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Luck Dragon: Asszociációs játék. :)
- 3DMark 11 eredmények
- sziku69: Szólánc.
- Alkoholista nevelde
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Vivo X200 Pro - a kétszázát!
- Battlefield 6
- További aktív témák...
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Jogtiszta Windows - Office & Vírusirtó licencek- Azonnal - Számlával - Garanciával - Nint.hu
- Eladó Steam kulcsok kedvező áron!
- Assassin's Creed Shadows Collector's Edition PC
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Lenovo IdeaPad Gaming 3 - 15.6" FHD IPS 165Hz - Ryzen 5-5600H - 16GB - 512GB - RTX 3050 Ti - Win11 P
- LG 27GR95QE - 27" OLED / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
- Lenovo magyar laptop billentyűzetre van szükséged? Akármelyik verzióban segítünk!
- Samsung Galaxy Tab A8 32GB, Újszerű, 1 Év Garanciával
- MacBook felvásárlás!! Macbook, Macbook Air, Macbook Pro
Állásajánlatok
Cég: FOTC
Város: Budapest