Dva roky uptime na PC s Windows aneb příběh jedné sázky (diskuse)

[První!]

Z toho místní linuxáky klepne pepka

[kralyk z abclinuxu]

Celkem souhlasim, že grafickej stack Windows je +- lépe navrženej než linuxovej (nakolik to můžu posoudit), ale stejně bys mohl nějak konkretizovat, v čem má být ten problém s Xorg nebo Waylandem. Já jsem žádnej problém nezaznamenal už roky. Uptime mam sice obvykle jen v řádu týdnů (kvůli updatům jádra), ale IMO i tak by se už muselo projevit...

[kralyk z abclinuxu]

Dtto s2ram, už ani nepamatuju, kdy s tim byl naposled problém. Možná jsi měl nějakou smůlu na ovladače...

[David Heidelberg]

Praticky vzato, s X problémy budou kvůli designu a stáří (zpětná kompatibilita je svinstvo, pokud je v rozsahu nad 20 let). Omylem pustím nějakou divně navrženou aplikaci a Xorg se zcvokne.

Co se týká Waylandu, "grafický stack" v podobě návrhu by tak ten poslední rok mohl být přiměřeně stabilní (aneb doba kdy ho většina projektů ho začla brát vážně).

Třeba v případě GNOME (gnome-shell) nebo kompozitorů postavených na wlroots bych si risknul se vsadit, u kwin z KDE bych vsadil na pád do týdne při běžném používání.

[Jendа]

A Wayland umí nezabít „klienty“ když padne „server“? (používám Xkovou terminologii) Tak jak autor článku požaduje a tvrdí že mu to funguje na Windows -- přijde mi to jako zajímavá vlastnost, byť si myslím že bych ji nevyužil moc často, protože mi Xka nepadají.

[Jendа]

Já bohužel musím potvrdit, že se mi stávalo na různém HW, že se jednou za několik měsíců (tj. stovky uspání) neprobudil a vytuhl. Teď jsem si zrovna vylosoval stabilní kombinaci HW a kernelu, takže se mi to neděje a mám pocit že poslední nechtěný reboot byl když jsem zmáčkl power button když už to bylo probuzené :).

[Tom K]

Hezké. Za mě můžu říct, že pracovní linuxový desktop mi běží bez problémů jednotky měsíců bez restartu. Pracovní notebook přežívá uspání do RAM a ve výsledku taky běží měsíce. Čas od času nějaký ten restart kvůli aktualizacím. Windows také běží bez problémů a dlouho (ve virtuálkách, ale to se taky počítá). Takže podle mě v normálních podmínkách všechny tři systémy nemají problém zůstat naživu tak dlouho, jak je třeba (ano. i MacOS).

[MM]

V práci mám PC, kterej má uptime 6 let, a reálný 1 rok provozu by mohl mít,... Ze začátku jel 8.5h/prac den. V posledním roce jsem ho ale pustil ale cca jen 3x, kvůli velmi starým projektům (ještě je 32bit, archlinux), nyní používám NB. Hibernuju... jinak programování c, web (ten už radši teď ne), pdf manuály, maily,... embedded...

[MM]

Jinak ten NB restartuji kvůli aktualizacím cca 1 za 1-3 měsíce, uspávám do RAM přes noc a víkendy (vyplé napájení), nyní je zahibernovaný.

[David Ježek]

Proč by to Linux na X či W nepřežil? Nějak jsem si toho za poslední roky nevšiml, byť musím uznat, že uptime 2 roky nemám. Tak nějak mi stačí uptime mezi aktualizacemi jádra, tedy řekněme jednotky týdnů maximálně. Ale nemohu soudit, provozuji PC se dvěma DIMM moduly, na druhou stranu já bych se na uptime této délky nedostal ani se svěcenou vodou, neb občas u nás ve vidlákově dojde k výpadku elektřiny, který než to matlové postupně nahodí (výpadků je v řadě tak 5-15), může trval i půl dne i více. Tak nabušenou UPSku bych platit nechtěl.

Jinak tím žes ty W10 neaktualizoval, si svému záměru jedině pomohl. Serou se většinou právě jen v souvislosti s aktualizacemi (i proto je já provozuji tak, že kritické mám odložené o měsíc a běžné o rok - pokud se tohle nastavení během posledních let nějak nezpřísnilo)

[Max]

Mě se děje to, že se objevuje bug v KDE5, kdy začne blikat a zamrzávat taskbar a pak i ovládání aplikací. Je to něco v posledních verzích s vsync a pomůže jen "kwin_x11 --replace". To ale není jediný problém. Pokud my některé java aplikace běží delší dobu (v řádu týdnů), tak se začne celé UI zpomalovat. 2x mi už celý stroj vytuhl. Je ale pravda, že mám v práci HP desktop s 32GB ram a v něm virtualizuji Win a celkově mám průměrné zatíženě úplně někde jinde, než autor zápisku. CPU mám v průměru 50% a ram 80%. Ten desktop nemá ECC. Chyba tedy může být na milionu místech :-/. Nicméně u posledního HP mi dělal výtuh stroje hw (i na Windows), takže začínám být vůči HP desktopu celkem skeptický. Jinak v dobách minulých, když jsem taktoval a hrál si s OC ve velkém, tak Linux dokázal rozpoznat sebemenší unstable takt. Tam, kde Win s OC běžely, tam Linux tuhnul, nebo nenabíhal. Tj, Linux byl minimálně v minulosti více citlivý na stabilitu hw, nežli win.
Zdar Max

[_]

lol a ted si predstav ze ja sem schopen xorg na linuxu restartovat bez vypnuti celeho OS ale proc bych to delal kdyz xorg s uptime v radu mesicu slape jak hodinky

[Tomt]

Ale s tim xorg ti chcipnou i spustene softy takze to je nahovno. To uz muzes restartovat a neni v tom rozdil.

[Gilhad]

Chcípnou jen ty v tom daném xorg - ostatní běžící v dalších xorg nejsou dotčeny, stejně jako ty, které vůbec nezávisí na GUI (což často bývají ty nedůležitější)

[hefo]

Často bývajú a často zas nie, na desktope skôr nie ako áno...

[xsubway]

Nějak mě to neoslovilo. Kolik to vidělalo dolarů? Kolik času tě stálo to sledovat a napsat tento blog v porovnání s tím ... no nech to plavat.-)

[z_sk]

Prečo nie Linux? Systém botneš v CLI režime (runlevel 3) a spustíš GUI manuálne (cez startx alebo nejaký príkaz pre prostredie cez Wayland).

[Manjaro++]

Pre menej inteligentnych - ak to chces spravit na linuxe tak pad Xwin alebo Waylandu znamena prehratu stavku. Je rozdiel mat uptime kernelu a uptime grafickeho desktopu.

[MakeIranBombedAgain❗]

ale zase jako když ti spadne gui ve windows tak to je asi jako konečná a mužeš to akorát restartovat zatimco v linuxu mužeš furt pokračovat v tui :P ;D

[xxxs]

tui firefox/chomajzl a pod, tui open office, tui gimp... mas?

[MakeIranBombedAgain❗]

lynx emacs/unoconv image-magick :O ;D

ale záset se jako nebudem :D :D :D ;D

[xxxs]

skor ide o to, ze vacsina desktopovych aplikacii je v gui a ked sa to zrube, tak pa pa.

[Jendа]

Přitom to zní jako celkem zbytečný problém architektury - například když zabiju třeba xfwm4, tak aplikace stále žijou, jenom s jejich okny nelze pracovat. Ale jakmile zase wm spustím (dokonce to snad jde i s jiným wm - můžu spustit třeba fluxbox), tak si okna posbírá a zase všechno funguje.

Stejně tak pokud přijdu o terminál/umře SSH spojení, tak terminálové aplikace stále žijí, dokud jim někdo nepošle HUP, a pokud používám program jako například screen/tmux (nebo lowlevelověji reptyr), tak se k nim lze opět připojit a bez problému pokračovat.

Jenom ukončení Xek je fatální. Ale nemuselo by. Na druhou stranu, mně naštěstí padají Xka tak naprosto výjimečně, že mi to nepřijde důležité.

[kvr]

Problém architektury to je, ale vyvaroval bych se slova "zbytečný". X má v sobě milióny dočasných objektů, které jsou referencované a potenciálně sdílené aplikacemi. Některý stav může být navíc uložený jenom v HW, na serveru nebo na klientu a k tomu všelijak rozsynchronizovaný. Vyřešit tohle už v tak komplikovaném X protokolu by byla pěkné peklo a jak říkáš - vzhledem k tomu, že pády se prakticky nevyskytují (a když už, tak můžou stejně sestřelit celý systém), tak je to problém, který nemá smysl řešit.

Pro porovnání, ten terminál řeší jen konexi na druhou stranu a předpokládám, že obnova připojení pošle request na redraw (asi změna vlastností terminálu) a zbytek neřeší (v nejlepším případě by si ještě mohlo udělat snapshot).

[Gréta stan]

Gréto tohle je pro tebe

[Want]

Čím vyšší uptime, tím větší stres. Chlubit se tím může jen pitomec.

[User682]

zdravim,

muzete rici proc neprovozujete stroj na Linuxu ?

Ono se to vcelku dost nabizi na virtualni stroje a nejake servery. Podle mne je Linux na serveru vykonnejsi. Nejaky vykon Vam asi sezere antivir(25-50% obcas nebyl problem). Pri vyssim load-u to linux lepe ustoji.

Nesnazim se Vam rikat, ze je nutne delat na Linuxu, ale mne to prijde pri tomto setup-u a mnozstvi aplikaci jako logicka volba.

Masina vypada velmi pekne. 32-core CPU Threadripper 3xxx rady je cenove hodne zajimavy. 64 jadra jsou uz trosku vice drazsi a v dnesni dobe spatne sehnatelna.

Pro nektere ostatni diskutery: pred casem me tady lidi 'zhejtovali' za 64+32 core CPU na Linuxu a dneska je tu v teto diskuzi ticho. Tak nevim, co je spatne.

Neco pro zajimavost: Delal jsem ted nejake vypocty se stahovanim dat pres internet. Stacilo otocit anteny na WIFI sitovce o 180 stupnu a load masiny sel dolu (asi nejzajimavejsi vec), ping-y a rychlost stahovani se zlepsily. Misto 11 instanci se da pustit 15 pri stejnem zatizeni. Smutny pribeh. Zazitku by se naslo vice.

gf

[Want]

..pred casem me tady lidi 'zhejtovali' za 64+32 core CPU na Linuxu a dneska je tu v teto diskuzi ticho.

Zkus zapřemýšlet. Linuxáky, co tu zbyli jeho uptime nezajímá a hejtři neví co si s tou informací počít, aby si nenasrali do vlastního hnízda.

[kralyk z abclinuxu]

Pro nektere ostatni diskutery: pred casem me tady lidi 'zhejtovali' za 64+32 core CPU na Linuxu a dneska je tu v teto diskuzi ticho. Tak nevim, co je spatne.

Nikdo tě pokud vim nehejtoval za nějaký jádra nebo jiný HW. Hejt jsi dostal za vnucování investice do silného HW lidem, kteří ho nepotřebují, případně už ho dávno mají...

[PamětníK]

Pro nektere ostatni diskutery: pred casem me tady lidi 'zhejtovali' za 64+32 core CPU na Linuxu a dneska je tu v teto diskuzi ticho. Tak nevim, co je spatne.

Uhm, vždyť jsi tu byl (a stále jsi) právoplatně za mamlase, když ses posmíval lidem s menším počtem jader než ty.

[User682]

Kdyz uz si tady hrajete na svedomi lidu, tak budte od te dobroty a sdelte nam alespon anynymne, co a jak bych vlastne mohl svobodne psat, aby Vam to nevadilo.

gf

[PamětníK]

Piš si co chceš, jakožto blbeček se do toho stejně promítne tvoje osobnost a lidem se to S-V-O-B-O-D-N-Ě nebude líbit.

[User682]

Treba mi tady nabizite lepsi zivot, kdyz se budu spravne vyjadrovat a ja o nej nechci prijit. Mohl konkretne sdelit, co mam psat, aby vse bylo podle Vas OK ?

[trekker.dk]

To je docela blbé, když tady teď požadujete radu ohledně něčeho, co se probíralo v mateřské školce...

[!]

Ty seš ale kus.. zralý na utracení.

[PamětníK]

Nějak tě to rozrušilo, zapomněl ses podepsat "gf". Mám podezření, že ti někdo ukradl účet nebo chlastáš Bez podpisu nevíme kdo jsi.

Zdar Max.

[oIo]

Tady je teba znacna poptavka po erotickych pribezich linuxaku (s holkama, aby bylo jasno)!

[kralyk z abclinuxu]

Kdyz uz si tady hrajete na svedomi lidu, tak budte od te dobroty a sdelte nam alespon anynymne, co a jak bych vlastne mohl svobodne psat, aby Vam to nevadilo.

Nic.

Cokoli napíšeš, nejspíš to bude vždycky někomu vadit.

[verteneverte]

jak zadupal LE do zeme svym impotentnim fasistickym vedenim lidi nezapomenou

[MakeIranBombedAgain❗]

tak von má jenom nějakej slabej socka cpu 3970 zatimco ty máš premiovej 3990 v hodnotě celýho tohodlectoho serveru jestli si jako dobře pamatuju :D ;D

[multi]

Kvalitni HW v kombinaci s odladenymm SW to je bezne i na linuxu. Ostatne to dokazuje embedded HW.

[Max]

Děkuji za zajímavý zápisek. Překvapilo mě nepoužívání ECC, když má člověk TR.
S uptime ohledně Linuxu souhlasím. Na svém pracovním PC v práci se nedostávám na uptime přes 2 měsíce. Podezřívám jednak hw (HP desktop bedna, co se tváří jak naleštěné lejno), tak i sw (xorg / gpu).
Jedu ale rollup, takže počítám s tím, že mohu mít problémy. Je možné, že kdybych naladil třeba Debian stable, nebo Ubuntu LTS, tak bych byl více stable, nevím.
Jinak reálně mým záměrem stejně není mít velký uptime, potřebuji aktualizovat, notebook používám zase jen sporadicky, takže tam nedává smysl ani uspání do ram atd.
Pokud jde o servery, tak u nich drží jak win, tak linux.
Máme ale asi 3 stroje, kde běží W2012R2 a Win10 a v těch strojí běží spousta desktop app. Mám zkušenosti, že jak na W2003, W2008, W2012R2, tak i na Win10 se stává to, že to explorer nedává a jednou za čas se dostane do prapodivného stavu a je třeba ho otočit.

Pokud jde o ESET, tak všechny AV dělají MITM a jen blázen si to nechává zapnuté. Já mám MITM vypnuté jak pro web, tak pro mailovou komunikaci. Tím chci říci, že zbavovat se ESETu nemá smysl, spíše bych to vypnul a poladil si HIPS filter .
Zdar Max

[User682]

zdravim,

okolo tech ECC pameti, tak take je nemam.

Pokud date 35kKc az pameti v 5/2021, tak se Vam uz moc preplacet nechce. Dneska uz jsou ceny jinde a uz bych o nich uvazoval. Tolik se mi investovat nechtelo. Ale jsou lidi, co to daji.

S pametmi jsem mel problemy pred asi 15 lety nejmene. Jinak ne. Nevidim v tom prinos.

Bud delam veci, kde jsou nejake vykonove spicky anebo bezi nejake ulohy, ktere se daji delit a ztrata neni v dnech ci hodinach.

Pokud by neco zhavarovalo, treba pameti, tak prepnu na druhy pocitac, co tu mam v zaloze a obcas se pouzije.

Uptime take neresim. Precijenom 80W v klidu neco taky sezene a je zbytecne teplo v mistnosti. Kdyz masinu potrebuji, tak na ni delam. Nekdy jen pres den. Nekdy bezi 3 dny v kuse.

gf

[Max]

Takže je urban legend to, že třeba vývojář zbytečně řeší debugování aplikace, která mu na jeho železe padá (třeba už při kompilaci), protože má vadnou ram? Nevím, jen se ptám. Ze své zkušenosti jen vím, že spolehlivě otestovat paměti moc nejde a už vůbec né u větších kapacit v nějakém reálném čase.
Zdar Max

[Tom K]

Mě se to reálně stalo cca deset let zpátky. Zbytečné ladění trvalo asi tři dny a protože už mi to fakt přišlo divné, pro jistotu jsem udělal memtest a bylo jasno. Šlo o aplikaci, která využívala skoro celou dostupnou paměť. Takže měla velkou šanci že se do chyby strefí. A protože alokace jsou svým způsobem deterministické, tak se chyba neprojevovala náhodně ale docela deterministicky, takže to vypadalo na chybu v kódu.

[Max]

Problém je, že memtest u 256GB ram neuděláš nijak lehce.
Zdar Max

[Jendа]

Čekal bych tak jednotky hodin, ne? Memtest (používám ten uzavřený od passmarku, protože ten originální ještě nedávno neměl UEFI verzi) je překvapivě rychlý, řekl bych že 16 GB otestuje tak za 15 minut. Snad to neznamená, že testuje nekvalitně.

[Max]

Naposledy, když jsem to zkoušel, tak to bylo s tou OSS verzí a u 256GB bych se dostal na 24h v rámci jednoho pass? A free verze toho komerčního zase nemá všechny testy a kupovat jsem to nezkoušel. Také se mi stalo, že mi memtest vyhazoval chyby, a to jen proto, že danou konfiguraci nepodporoval. Ale je to už dlouhá doba. Pak jsem na memtest zanevřel (špatná kompatibilita a dlouhá doba testování mi říkalo, že to není moc objektivní).
Možná je to všechno dnes už jinak, nevím. Nejdraději bych řešil spíše prevenci, než proaktivní kontroly. Tj. používal plnohodnotně ECC.
Každopádně naposledy jsem pro test pamětí používal stressapptest, ale ten má tu nevýhodu, že se spouští z OS a nedokáže otestovat celou paměť.
Zdar Max

[k3dAR]

BTW: pred par mesici vysla verze 6:

V6.00 Changelog
Rewrite code for UEFI 32 & 64 bits
Add support for x64 Long Mode Paging
Add support for up to 256 cores
Add detection for DDR4 & DDR5
Add support for XMP 3.0
Add detection for AMD Zen 1/2/3/4
Add detection for Intel up to 13th Gen
Add better support for AMD pre-ZEN CPUs
Add support for older nVidia and AMD chipsets
Add support for SDRAM
Many enhancements
Numerous bug fixes & optimization

je dostupna v "kernel" formatu, takze snadno spustitelna i z iPXE legacy/uefi

[Jendа]

A free verze toho komerčního zase nemá všechny testy

Podle https://www.memtest86.com/compare.html chybí jen SSE, ne?

[Want]

Přesně tak. Navíc některé chyby se projeví jen když jede modul v páru. Ty jsou nejzákeřnější.

[User682]

zdravim,

co mam zkusenosti z praxe, tak HW vetsinou funguje. Za par let se vzdy neco stane. A nejlepsi reseni, co znam, je mit druhou masinu. Spise dalsi 2. 2x pracovni stanice + notebook.

Mozna, ze je hodne rozdil v tom, kdyz koupite treba zakladni desku za minimalne 12kKc, protoze levnejsi se moc koupit neda. Zpetnym pohledem musim rici, ze co jsem presel z beznych PC pro uzivatele na pracovni stanice/HEDT hardware, tak hodne problemu ustalo. Do toho nekupuji uplne nejlevnejsi HW nebo nezname znacky, protoze mi to ve finale uspori hodne casu.

Co je asi nejvetsi riziko, je kdyz delate upgrade distribuce nebo upgrade HW. K tomu potrebujete druhy stroj. Treba proto, ze neodhanete chladic CPU. AMD 3990x uz vzduchovy chladic nedal a v zatezi to nahodne padalo. Nebo, ze Vam nejede RDP klient a zjistite to az pozde.

Hodne velka vyhoda Linuxu je, ze pokud Vam neco nejede 2-3 hodiny a do toho na Vas padne produkcni chyba, ze muzete vytrhnout disk z pracovni stanice a dat jej do druhe masiny/stanice/notebooku a pokracujete dale. Pak doresite nasledky/pricinu, proc prvni stroj nejede.

Nejake problemy s pameti, nebo CPU (nejake AMD 8 jadro) jsem uz resil.

Zalohy resim prubezne. Asi nejlepsi zaloha hodne dulezitych veci je GIT. Zdrojaky a dokumentace.

Casteji se mi stava parkrat do roka, ze nejede internet nebo infrastruktura zakaznika - VPN, servery, neco se zarizlo na F5, vypadek diskoveho pole, ..... Zrovna v patek minuly tyden jsem byl neco resit u klienta, nejela WIFI a do toho padla produkcni chyba, ktera nastesti byla ve finale nizsi priority.

I tak se bez vykonne pracovni stanice v nejhorsim obejdete. Co delam vyvoj, tak to se da delat i na 1 core CPU + 8-16 GB RAM. Akorat to trva. Nejake vypocetne narocne veci, tak to jsou veci, co zase tolik nespechaji v pripade vypadku. Plus do toho nejaky data-mining delate klidne vicekrat na stejnych datech. Obcas se neco nepovede, neznama data... a pocitate to znovu.

gf

[Ovoce]

Parádní pokus a hec :) A výsledky zajímavý. (ˇvˇ)b

[trekker.dk]

Wayland ani Xorg by to tak dlouho nepřežily.

To bude rukama, na svém starším počítači jsem při pravidelném suspend to disk nahrabal nějaké ty měsíce uptime - pak update jádra, neměl jsem holt potřebu se s někým sázet.

[disorder]

Dalo, nedalo. Mne X11 pada niekde v intel driveri.

Windows naproti tomu mi svojimi nastahovanymi updatami vyziera disk a uz mi kvoli tomu sposobil aj stratu dat. A viackrat sa mi stalo, ze som musel pre istu funkcnost robit suspend navyse aby sa nieco prebralo. Niekedy ani to nepomaha a musim ho nechat updatovat aby sa system "vycistil". Nebezi na nom takmer nic, jedna hra, jeden zlahka pouzivany chrome a Kodi.

[disorder]

K tomu intelu by som len dodal, ze sa mi to asi deje az od upgradu na Skylake. A jedna sa o instalaciu Debianu datovanu od roku 2007.

[Max]

O stáří instalace nejde, pokud máš aktuální verze. Každopádně Intel své drivery za posledních 15let přepisoval asi 3x. Podpora GPU se pak překrývala v rámci oněch ovladačů. Je tedy otázkou, zda vůbec používáš správný ovladač na svojí GPU.
Zdar Max

[disorder]

Urcite ano, pretoze na zaciatku som ten ovladac nevymenil a jeho vymena nepomohla. Potom som si sluboval cosi aj od vymeny VAAPI ovladaca a to tiez nepomohlo. Povodne aj tie logy nic zaujimave neukazovali, ale teraz sa tam zacina objavovat pred crashom nejaky zlyhany alloc (moze za to urcite nenazrany chrome s vela tabmi).

(WW) glamor: Failed to allocate 48x48 FBO due to GL_OUT_OF_MEMORY. (WW) glamor: Expect reduced performance.

potom viacero opakovani a crash

glamor0: GL error: GL_OUT_OF_MEMORY in glMapBuffer(map failed) glamor0: GL error: GL_INVALID_OPERATION in glUnmapBuffer(buffer is not mapped)

Segmentation fault at address 0x4

[disorder]

Ale teraz pozeram popis balicku:

The use of this driver is discouraged if your hw is new enough (ca. 2007 and newer). You can try uninstalling this driver and let the server use its builtin modesetting driver instead.

...to nie je velmi pekne, ze to treba odinstalovat, ale asi sa nepouziva: modeset(0): glamor X acceleration enabled on Mesa Intel(R) HD Graphics 520 (SKL GT2)

[David Heidelberg]

1. crocus není zrovna nejvíc udržovaný driver, takže bohužel už máš docela starej HW. Každopádně to by problém být neměl.

2. chcípá to v nouveau_drm_screen_create WTF?! Co Intelí ovladač dělá v Noveau (nvidia) kódu

3. nainstaluj debug balíčky a bumpni ten bug, že je aktuální s novým crash reportem (s debug balíčky to bude dávat i smysl).

apt install libbsd0-dbgsym libdrm-amdgpu1-dbgsym libdrm-nouveau2-dbgsym libdrm-radeon1-dbgsym libdrm2-dbgsym libedit2-dbgsym libelf1-dbgsym libexpat1-dbgsym libffi8-dbgsym libgcc-s1-dbgsym libgl1-mesa-dri-dbgsym libglapi-mesa-dbgsym libicu71-dbgsym liblzma5-dbgsym libmd0-dbgsym libsensors5-dbgsym libstdc++6-dbgsym libtinfo6-dbgsym libvulkan1-dbgsym libxml2-dbgsym libz3-4-dbgsym libzstd1-dbgsym zlib1g-dbgsym by mohlo stačit

https://gitlab.freedesktop.org/mesa/mesa/-/issues/7626

[disorder]

Ja mam intel, v ziadnom nouveau_drm_screen_create to nepada:

[555404.703] (EE) Backtrace:
[555404.710] (EE) 0: /usr/lib/xorg/Xorg (?+0x0) [0x5615fce12435]
[555404.710] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (?+0x0) [0x7ffb03e09140]
[555404.715] (EE) 2: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7ffb02775216]
[555404.716] (EE) 3: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7ffb0263dade]
[555404.717] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7ffb01b8f87b]
[555404.717] (EE) 5: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7ffb01b93b7f]
[555404.718] (EE) 6: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7ffb01d23e17]
[555404.718] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7ffb01d270bc]
[555404.718] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7ffb01d2cc75]
[555404.719] (EE) 9: /usr/lib/xorg/modules/libglamoregl.so (?+0x0) [0x7ffb032d96bf]
[555404.719] (EE) 10: /usr/lib/xorg/modules/libglamoregl.so (?+0x0) [0x7ffb032d5f85]
[555404.719] (EE) 11: /usr/lib/xorg/modules/libglamoregl.so (?+0x0) [0x7ffb032d3461]
[555404.719] (EE) 12: /usr/lib/xorg/Xorg (?+0x0) [0x5615fcd91e3f]
[555404.719] (EE) 13: /usr/lib/xorg/modules/libglamoregl.so (?+0x0) [0x7ffb032daae1]
[555404.719] (EE) 14: /usr/lib/xorg/Xorg (?+0x0) [0x5615fcd86b48]
[555404.720] (EE) 15: /usr/lib/xorg/Xorg (?+0x0) [0x5615fccae584]
[555404.720] (EE) 16: /usr/lib/xorg/Xorg (?+0x0) [0x5615fccb2584]
[555404.720] (EE) 17: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7ffb03c54d0a]
[555404.720] (EE) 18: /usr/lib/xorg/Xorg (?+0x0) [0x5615fcc9bd1a]
[555404.720] (EE)
[555404.720] (EE) Segmentation fault at address 0x4

Mam xserver-xorg-core-dbgsym a este pre intel ovladac, ale kedze ten sa zrejme nepouziva... Nabuduce asi skusim switchnut na stary ovladac, ak to podporuje, lebo pada to tak raz za 1-2 mesiace, pravdepodobne ked sa prilis naplni pamat.

[disorder]

Pozeram odlozene logy, pred vymenou drivera to padalo aj v i965_dri.so a zda sa mi, ze intel driver som odstavil z pouzivania este pred Skylake v roku 2012.

Odkedy som switchol z i965 na iris, tak sa zacali objavovat tie glamor chyby.

Debug symboly tam mam nainstalovane uz aspon rok, asi odvtedy kedy som zmenil i965 na iris (2021/4) a v logu sa neobjavili ani raz. Logov mam odlozenych asi 18, ale po zmene na iris vidim aj dva kde je miesto neho libfb.so, ale backtrace a chyby vyzeraju velmi podobne:

glamor0: GL error: GL_OUT_OF_MEMORY in glTexSubImage
glamor0: GL error: GL_OUT_OF_MEMORY in glMapBuffer(map failed)

[David Heidelberg]

Dle logu je jasny, ze nemas DBG symboly pro mesu. Kazdopadne, jestli chces pripis logy s chybama (ale nejaky uzitecny, ne tohle) do toho bugu a nekdo na to snad mrkne.

[disorder]

tak to padlo a backtrace je rovnaky:

libc6-dbg:amd64					install
libdrm2-dbgsym:amd64				install
libgl1-mesa-dri-dbgsym:amd64			install
libglapi-mesa-dbgsym:amd64			install
xserver-xorg-core-dbgsym			install
xserver-xorg-video-intel-dbgsym			install

od minula som tam doinstaloval tie mesy, pridavam libgcc-s1-dbgsym. neviem co je potrebne aby to vobec zacalo fungovat, neviem najst taku informaciu

[MakeIranBombedAgain❗]

že to má děsně moc moc chvostů :O :D :D ;D

[Linux]

Já se připojuju k těm, kteří s uptime na Linuxu nemají problémy. Ještě na škole jsme se pohybovali běžně v měsících, akorát to žralo energii. Dneska na laptop, který pravidelně usíná (ale nepadá) je to otázkou týdnů až nižších měsíců (useknutých upgradem, ne pádem). Na pracovním MacOs mám teď 30 dní čistého času (a budu restartovat kvůli upgrade). U Linuxu jsem měl jediný problém s X adaptérem na Wayland, který občas spadnul a sestřelil X aplikace. Pak jsem se vrátil zpátky na čisté X a problém zmizel. U MacOs aarch64, u Linuxu relativně moderní CPU (předchozí 2014, teď 2021).

[O'ojam]

Na Linuxu s tim neni problem.

Suspend: Lenovo Thinkpad T470s s Debianem suspenduji bezne 3-10x denne a uptime miva mnoho mesicu. Nejcastejsi pricina restartu je blbe umistene vypinaci tlacitko, za ktere ho omylem vezmu, kdyz z nej v aute prehravam muziku a chci ho jednou rukou zvednout a kouknout se na mapu.

Uptime: Na serveru s Debianem, na kterem mi ve screenu bezi vetsina desktopovych aplikaci (krome browseru) jsem mel pres 700 dni a pak odesel jeden z disku a musel jsem ho vypnout. Na workstation s Debianem, Xorgem a fluxbboxem jsem uz teke mel nekolikrat pres rok uptime. V lete jsem vymenil pocitac, takze ted takovy uptime nemam, bude potreba pul roku pockat. Tam je problem se suspendem - s pripojenymi USB-C->HDMI redukcemi se to odmita suspendovat.

[Weltende]

Ja mel na serveru s debianem uptime 10 let. A co jako?

[Tom]

To je tak, kdyz nekdo komentuje aniz by cetl, co vlastne komentuje a udela si tim trapas O stabilite linuxu na serveru nikdo nepochybuje. Jakmile se tam ale zacnou delat mene standardni desktopove veci (hrani her + 3 monitory + video, TV karta,...) tak to zacne jit do kopru. Jinak moje zkusenost s uspavanim je takova, ze to vetsinou funguje ok. Kdyz ale zapomenu, ze mam na pozadi 3D hru a uspim to (to se mi stava hlavne s PoE, ktery musi bezet aby clovek mohl neco prodat), tak je casto problem (ze spadne ta hra, to bych cekal ale ono to casto skonci cernou obrazovkou po probuzeni a resi to az restart).

[Podzim]

Vyloženě závidím. Taky bych chtěl mít času na řešení takových hovadin.