Debian Stretch mrznutí grafiky po hibernaci

[jmk]

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.

Kód: [Vybrat]

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" 

[Reklama]

[Neviditelný]

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.

[jmk]

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 

[ByCzech]

Výstup z dmidecode by byl?

[JardaP .]

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.

[Reklama]

[jmk]

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

[JardaP .]

No tak odinstalovat to sshd je otazka jednoho prikazu. Jestli sit zije by rekl ping, otazka je, jak moc zije.

[ByCzech]

Díky za dmidecode...

Koukal jsem, že pro váš stroj je k dispozici novější BIOS/UEFI firmware. 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.

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

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

[ByCzech]

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

[Neviditelný]

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

Kód: [Vybrat]

systemctl stop gdm, přihlásit se z konzole a nahodit jenom ty nejelementárnější Xka

Kód: [Vybrat]

startx. Odtud systém ručně uspi

Kód: [Vybrat]

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 )

[jmk]

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

Kód: [Vybrat]

systemctl suspend jsi chtěl napsat

Kód: [Vybrat]

systemctl hibernate 

Díky!

[Fantomas]

V tom logu X-ek ti vykazuje nejake chyby ovladac na Synaptic touchpad, nemuze byt v tom chyba?

[jmk]

myslíš toto:

Kód: [Vybrat]

[    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 ?

[ByCzech]

@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ý]

@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

Kód: [Vybrat]

systemctl suspend jsi chtěl napsat

Kód: [Vybrat]

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?