Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: jmk 09. 05. 2018, 23:17:47
-
Ahoj,
vcelku ohrané téma - mrznutí grafiky na Linuxu, nicméně mám trochu jinou variantu :)
Instalace : Debian 9, Gnome, up-to-date k dnešnímu dni.
uname -a : Linux skynet 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1 (2018-04-29) x86_64 GNU/Linux
Projevení závady : po hibernaci systému, (která se provede korektně) tak systém při obnovení z hibernace naběhne, ale po zalogování cca do 1-2 sekund X-ka zamrznou - jde pouze pohybovat myšítkem, ale pochopitelně na nic nereaguje. Nicméně např. kliknutí myšítka se bufferují, protože, když při zamrznutých X-kách kliknu na spuštění aplikace tak po "odmrznutí" se mi tato aplikace spustí jakoby nic. A teď to zajímavé - odmrznutí nastane vždy po 32 sekundách. Projeví se to tak, že prostě systém zase reaguje normálně - ani neproblikne obrazovka, jako kdyby se třeba X-ka resetovali.
Pátrám, kde může být problém. Zatím dávám do přílohy jaký mám hardware a výpis z dmesg , /sys/class/drm/card0/error - viz odkaz v dmesg, lspci - v , ale nejsem z toho vůbec moudrý.
Ještě jeden hint - toto zamrznutí se stává, až u druhé a další hibernace - napoprvé proběhne wakeup z hibernace naprosto bez problémů plynule bez zamrznutí.
Díky za nasměrování, kde pátrat, kde poGooglit. Předem díky za váš čas - prohlížení logů je vždy "lahůdka" >:(
-
No jestli mrzne jen GUI - dá se přepnout to jiného VT? - chtělo by to spíš log Xek. Jestli se lze přepnout do jiného VT, zkus to udělat a mrkni se, zda nějaký proces po těch kritických 32 sekund nežere podezřele moc CPU. Mně něco podobného dělá po probuzení Plasma; taskbar, KRunner apod jsou po několik sekund po resumu mrtvé, pak se probudí a všechno běží jakoby nic. Zatím jsem nevysledoval, čím to je.
-
do jiného VT se přepnout nedá. klávesnice nereaguje. že by byl systém vytížený to se mi nezdá. větrák je v klidu. když to zamrzne tak se zastaví samozřejmě i ukazatel hodin, který pak přeskočí právě o těch 32s :)
-
Výstup z dmidecode by byl?
-
do jiného VT se přepnout nedá. klávesnice nereaguje.
Tak si rozchodte ssh pres klice, abyste to jen odklepl a jelo to, tedy za predpokladu, ze i sit neni 32s tuha.
BTW, nejak nevidim, co mate za DE.
-
@ ByCzech, dmicode jsem neznal - docela podrobný výpis HW - přikládám v příloze.
@ JardaP, Gnome 3.22 - viz původní příspěvek. instalit SSH na stroj kvůli debugu tohoto se mi zatím fakt nechce - hlavně, když ani nevím jestli žije síť - to bubu muset ještě vyzkoušet.
Díky.
-
No tak odinstalovat to sshd je otazka jednoho prikazu. Jestli sit zije by rekl ping, otazka je, jak moc zije.
-
Díky za dmidecode...
Koukal jsem, že pro váš stroj je k dispozici novější BIOS/UEFI firmware (https://support.lenovo.com/cz/cs/downloads/ds101975). Určitě stojí za pokus aktualizovat, hodně často se tím takový problém vyřeší. Patříte ke šťastnějším majitelům PC/notebooku, pro které výrobce připravil i možnost aktualizovat BIOS/UEFI i bez Windows (https://support.lenovo.com/cz/cs/downloads/ds101953).
Pokud nepomůže mám další dotaz... Startujete notebook v režimu legacy (BIOS) nebo UEFI? Dost často u nových strojů je problém s legacy režimem, protože už na to prostě kašlou. Občas je i problém opačně. Takže by stálo za pokus vyzkoušet opačný způsob startu.
Jinak podle popisu to vypadá, že by stroj mohl bloudit někde v režimu SMM (Ring -2) (https://en.wikipedia.org/wiki/System_Management_Mode) a nemohl se z něj vrátit. To se řešilo často opravou DSDT tabulek z ACPI, které se nahrávaly ze souboru místo té chybné v ROM a/nebo požádání o tabulku určenou pro konkrétní verzi Windows ap. (https://wiki.archlinux.org/index.php/DSDT#Tell_the_kernel_to_report_a_version_of_Windows)
Také by nebylo marné vyzkoušet kernel z Debian backports. Už je tam 4.16 - včera mi přifrčel do mých strojů...
-
Ještě jsem ze zvědavosti koukal po netu a vypadá to, že problémy s probouzením jsou u těchto strojů i na Windows:
X1 Carbon, X1 Yoga do not wake up after sleep mode -- issue continues across thinkpad generations (https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/X1-Carbon-X1-Yoga-do-not-wake-up-after-sleep-mode-issue/td-p/3709271)
-
Dlouhá volání do SMM by byly v dmesg, mám dojem, že na jakýkoliv by SMM call delší než 30 sekund reaguje jádro kernel panicem. Zkusil bych prozkoumat efekt userspacu. Zkus po startu shodit GDM
systemctl stop gdm, přihlásit se z konzole a nahodit jenom ty nejelementárnější Xka startx. Odtud systém ručně uspi systemctl suspend a prober. Pokud ti to ztuhne stejným způsobem i takto, viděl bych to na nějaký problém s ovladači HW.
(Příkazy jsem psal z hlavy, kdyžtak mě někdo opravte :) )
-
@ByCzech : Startuji v UEFI. Bios jsem upgradoval cca před 2 měsíci, protože to mně napadlo také. Původně jsem tam měl nějaký originální BIOS z před dvou let a nyní je tam 1.24, dostupná je 1.25. Dle popisu nová verze BIOSu opravuje nějaké security chyby v Intel špiónech :), takže nepředpokládám, že by to pomohlo.
Ještě zkusím i backportované jádro - ale to je občas sázka do loterie, že nepůjde něco jiného. Kromě tohoto issue totiž funguje vše perfektně včetně suspend_sedation https://wiki.debian.org/SystemdSuspendSedation (https://wiki.debian.org/SystemdSuspendSedation). Problematika DST tabulek je pro mně něco nového - nastuduji.
@Neviditelný : docela přímočarý postup ;) vyzkouším akorát si nejsem jist zda-li v Debianu "startx" nenastartuje znovu GDM - na 99% si myslím, že ano. A pochopil jsem i to, že místo systemctl suspend jsi chtěl napsat systemctl hibernate ;)
Díky!
-
V tom logu X-ek ti vykazuje nejake chyby ovladac na Synaptic touchpad, nemuze byt v tom chyba?
-
myslíš toto:
[ 11.840] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/mouse0)
[ 11.840] (II) No input driver specified, ignoring this device.
[ 11.840] (II) This device may have been added with another device file.
[ 11.840] (II) config/udev: Adding input device TPPS/2 IBM TrackPoint (/dev/input/event12)
[ 11.840] (**) TPPS/2 IBM TrackPoint: Applying InputClass "libinput pointer catchall"
[ 11.840] (II) Using input driver 'libinput' for 'TPPS/2 IBM TrackPoint'
[ 11.841] (II) systemd-logind: got fd for /dev/input/event12 13:76 fd 30 paused 0
[ 11.841] (**) TPPS/2 IBM TrackPoint: always reports core events
no vypadá to trochu podezřele, ale netuším co s tím. Ručně jsem Synaptics nekonfiguroval - zůstal instal-default - což není záruka, že je to dobře ;) že by byl tady někde zakopaný pes https://wiki.debian.org/SynapticsTouchpad#Debian_9_.22Stretch.22 (https://wiki.debian.org/SynapticsTouchpad#Debian_9_.22Stretch.22) ?
-
@ByCzech : Startuji v UEFI. Bios jsem upgradoval cca před 2 měsíci, protože to mně napadlo také. Původně jsem tam měl nějaký originální BIOS z před dvou let a nyní je tam 1.24, dostupná je 1.25. Dle popisu nová verze BIOSu opravuje nějaké security chyby v Intel špiónech :), takže nepředpokládám, že by to pomohlo.
To by z popisu tak vypadalo, ale zkušenost říká něco jiného a sice, že ne všechny změny BIOSu/UEFI výrobci popisují, často řeší problémy, které vůbec v popisu nejsou.
Ještě zkusím i backportované jádro - ale to je občas sázka do loterie, že nepůjde něco jiného.
Žádná sázka do loterie, backports jsou oficiálně podporovány, vyzkoušeno dlouhodobě na množství strojů.
akorát si nejsem jist zda-li v Debianu "startx" nenastartuje znovu GDM - na 99% si myslím, že ano.
Ne nenastartuje - pokud se něco v nedávné minulosti zásadně nezměnilo.
-
@Neviditelný : docela přímočarý postup ;) vyzkouším akorát si nejsem jist zda-li v Debianu "startx" nenastartuje znovu GDM - na 99% si myslím, že ano.
To by snad neměl. Určitě ale kontroluj, zda máš nainstalovaný aspoň xterm, lépe i TWM. Jinak je zde ještě syrovější xinit.
A pochopil jsem i to, že místo systemctl suspend jsi chtěl napsat systemctl hibernate ;)
Herdek, až teď mi došlo, že fakt myslíš suspend-to-disk a ne suspend-to-RAM. S hibernací jsem míval podivné problémy, když jsem s tím kdysi machroval na starém notebooku; vzpomínám, že WiFi karta po probuzení vždycky zdechla a musela se resuscitovat znovunahráním modulu iwlwifi apod. Když už jsme u toho, běžný suspend (to RAM) je OK?
-
Tak jsem si pohrál s biosem a výsledek je následující:
- púvodní kombinace : Boot UEFI Only, CSM Support Yes : po obnovení z hibernace mrznou Xka po dobu 30s
- změna č.1 Boot UEFI Only, CSM Support No : po obnovení z hibernace zamrznou Xka a již nerozmrznou :D
- změna č.2 Boot Both, Legacy Boot First, UEFI Boot Second, CSM Support Yes : a světe div se, po obnovení z hibernace Xka nemrznou ;D
Všechny výš uvedené kombinace jsem poctivě zkoušel 3x po sobě a pokaždé se chovali úplně stejně. Takže závěr je, že problém zatím odstraněn i když dost dobře nevím proč - prostě kouzla v Biosu/UEFI - dá se říci spackaná implementace ACPI ?
@Neviditelný : suspend to RAM vždy fungoval bez problémů a funguje i nyní :-)
Chlapi díky za rady! Prozatím dávám jako solved do doby než mně můj oblíbený Debian nepřesvědčí o opaku ;D
-
změna č.2 Boot Both, Legacy Boot First, UEFI Boot Second, CSM Support Yes : a světe div se, po obnovení z hibernace Xka nemrznou ;D
[/list]
Všechny výš uvedené kombinace jsem poctivě zkoušel 3x po sobě a pokaždé se chovali úplně stejně. Takže závěr je, že problém zatím odstraněn i když dost dobře nevím proč - prostě kouzla v Biosu/UEFI - dá se říci spackaná implementace ACPI ?
Zpackaný firmware obecně. Číňani to lepí jako vrabec hnízdo a podle toho to pak vypadá. Zapne/vypne se legacy modul, povolí/zakáže boot tak či ona a už to jede jak vidno. A to máte štěstí, že to stačí jen zapnout a nemusíte měnit vlastní start OS z UEFI na MBR, jako se mi stalo u jiných strojů.
@Neviditelný: Ovladače to zjevně nejsou, ty jsou ve všech případech stejné... Kde to teda podle vás zůstává viset, když ne v SMM, když to v jedné kombinaci tazateli jede a ve dvou ne?
-
@Neviditelný: Ovladače to zjevně nejsou, ty jsou ve všech případech stejné... Kde to teda podle vás zůstává viset, když ne v SMM, když to v jedné kombinaci tazateli jede a ve dvou ne?
To, že ovladače jsou vždy stejné podle mě tolik neznamená. Záleži na tom, do jakého stavu nastaví firmware desky hardware po probuzení z hibernace a jak si s tím stavem umí ten který ovladač poradit.
-
Za UEFI by nekdo potreboval rozkopat prdel, to je asi nejblbejsi IT napad tohoto stoleti. Oni driv dokazali zprasit i jednoduchoucky BIOS, tak nevim, jak se nekdo mohl domnivat, ze by kdy dokazali dat dohromady funkcni UEFI. Tazatel ma stesti, ze mu aspon boot Linux nebricknul pocitac, jako to vymysleli soudruzi ze Samsungu.
-
@Neviditelný: Ovladače to zjevně nejsou, ty jsou ve všech případech stejné... Kde to teda podle vás zůstává viset, když ne v SMM, když to v jedné kombinaci tazateli jede a ve dvou ne?
To, že ovladače jsou vždy stejné podle mě tolik neznamená. Záleži na tom, do jakého stavu nastaví firmware desky hardware po probuzení z hibernace a jak si s tím stavem umí ten který ovladač poradit.
Ale to já si uvědomuji, proto se ptám, kde to vidíte. Možnost, kterou jste napsal si uvědomuji, ale jen to vyvolává další otázky...
Proč firmware nastavením věcí, které by takové chování vůbec měnit neměly po probuzení dává HW do stavu, který ovladač / kernel neustojí? Ovladače GPU jsou přímo od Intelu.
Proč se to umí zaseknout úplně, že s tím nejde udělat vůbec nic a vytuhne to komplet, zřejmě včetně kernelu?
Nebloudí to tedy v SMM, takže kernel s ovladači se pak nedostane k lizu?
Je ten stav, který firmware po probuzení vrací správný?
Proč je 3× jiný?
Je to tedy chyba v ovladačích nebo ve FW nebo část tady část onde?
Proč to na podobných strojích od jiného výrobce chodí bez problémů se stejnými ovladači?
Atd. našel bych jich hodně, které budou tlačit mysl spíše směrem k tomu, že chyba je ve FW nikoli v ovladačích... Navíc se to dle Google netýká jen Linuxu...
-
Za UEFI by nekdo potreboval rozkopat prdel, to je asi nejblbejsi IT napad tohoto stoleti. Oni driv dokazali zprasit i jednoduchoucky BIOS, tak nevim, jak se nekdo mohl domnivat, ze by kdy dokazali dat dohromady funkcni UEFI. Tazatel ma stesti, ze mu aspon boot Linux nebricknul pocitac, jako to vymysleli soudruzi ze Samsungu.
No Jardo, za tohle UEFI moc nemůže. Chování ACPI na daném stroji je problém. To že to výrobce zkryplí tak, že se to podle toho, jestli je/není legacy režim aktivní a je/není možné/umožněno z něj bootovat chová pokaždé jinak není chyba UEFI jako takového.
Nové stroje co skládám občas nastavuji obvykle tak, že legacy úplně vypínám, nechávám jen UEFI a obvykle to je to co nedělá problémy. To samé notesy. Že v Lenovu to mají domrvené a legacy moduly jim chodí lépe je věc jiná. Myslím si, že u FW by FOSS mohlo hodně pomoct, kdyby výrobci brali nějaké core části pro UEFI/BIOS a dělali si jen ty "omalovánky" nad tím, které manažeři tak žerou a to co podle marketérů tak prodává. Ideálně, kdyby to bylo jednoduše skinovatelné a byl by možná klid.
-
Myslím si, že u FW by FOSS mohlo hodně pomoct, kdyby výrobci brali nějaké core části pro UEFI/BIOS a dělali si jen ty "omalovánky" nad tím, které manažeři tak žerou a to co podle marketérů tak prodává. Ideálně, kdyby to bylo jednoduše skinovatelné a byl by možná klid.
To se nestane, to by bylo prilis inteligentni.
-
@ByCzech: BTW, ACPI a pred nim jiz APM byvalo zkurvene bezne jiz v BIOSech, ted k tomu misto zkureveneho BIOSu mame navic jeste zkurvenejsi UEFI.
-
@ByCzech: BTW, ACPI a pred nim jiz APM byvalo zkurvene bezne jiz v BIOSech, ted k tomu misto zkureveneho BIOSu mame navic jeste zkurvenejsi UEFI.
No to je právě ono, očividně nezáleží do jaké technologie to zabalí, jestli BIOS nebo UEFI, prostě ten power management vždycky (znovu) zkazí :D
-
No to je právě ono, očividně nezáleží do jaké technologie to zabalí, jestli BIOS nebo UEFI, prostě ten power management vždycky (znovu) zkazí :D
Jenze kdyz to bali do UEFI, ocividne sance jsou vetsi, viz https://forum.root.cz/index.php?topic=18440.msg264589#msg264589
-
No to je právě ono, očividně nezáleží do jaké technologie to zabalí, jestli BIOS nebo UEFI, prostě ten power management vždycky (znovu) zkazí :D
Jenze kdyz to bali do UEFI, ocividne sance jsou vetsi, viz https://forum.root.cz/index.php?topic=18440.msg264589#msg264589
A u spousty jiných jak jsem psal je to naopak lepší v UEFI only režimu. Takže to spíš ukazuje opět na matlaly z Lenova :D ne na UEFI jako takové.