Po powrocie z wygaszenia ekranu, ekran "zamraża się"

Z pozoru wygląda w porządku, ale wcale nie jest w porządku. Z logów wynika, że system nie został uśpiony, a mimo to próbuje się obudzić – trochę to nie gra. Sprawdź, czy w ustawieniach rzeczywiście masz włączone usypianie i czy masz aktywny TLP, jeśli nie to włącz:

systemctl status tlp

Jeśli to żadne z tych to sprawdź co ci siedzi w pliku /etc/systemd/sleep.conf – ja mimo, że mam wszystko zakomentowane to mi działa, ale może tak jest tylko w KDE.

Nie korzystam z tlp. Z tego co widzę, jest to pakiet przeznaczony raczej do laptopów, a ja mam desktop, zarządzany przez Menedżer Zasilania (xfce4-power-manager).
Nie korzystam z hibernacji i nie mam żadnego screensaver’a.
Tryb usypiania systemu mam określony jako “Wstrzymanie” (pisząc o usypianiu, chyba miałeś na myśli hibernację).
Wygaszenie ekranu objawia się tym, że gaśnie lampa podświetlająca ekran LCD.

Natomiast ostatnio problem z tego wątku się nie pojawia. Być może, przy okazji jakieś aktualizacji, sam się naprawił.

Skoro działa to nie ma potrzeby tego drążyć. Przez usypianie miałem na myśli efekt polecenia systemctl suspend – u mnie w KDE widnieje w ustawieniach po prostu jako usypianie. Chciałem się upewnić bo mam też inne opcje jak wyłączenie czy wstrzymanie ekranu.

Jeżeli wszystko masz zakomentowane, to znaczy, że działają domyślne ustawienia, które zostały by nadpisane, gdybyś odkomentował jakieś wiersze i zmienił wartości.


W potocznym i ogólnym znaczeniu (w odniesieniu do systemu):

  • hibernacja = zapis stanu pamięci na dysk i zamknięcie systemu;
  • usypianie = wstrzymanie = pozostawienie pod napięciem RAM’u i odcięcie pozostałych urządzeń.

Posiłkuję się terminologią z Menedżera Zasilania, gdzie w zakładce System>“Tryb usypiania systemu” można wybrać, albo “Wstrzymanie”, albo “Zahibernowanie”.

Terminologia zależna jest od fantazji programistów i tłumaczy. Bywa, że trzeba się natrudzić, aby dojść do tego, co autor miał na myśli. Aby nie opierać się na domysłach, czy potocznym rozumieniu i aby nie przedłużać OT fantazjami, definicje z Wikipedii:

Niestety, wracam do tematu, który, jak wydawało mi się, “sam” się rozwiązał.

Zauważyłem, że problem się ponownie pojawia, gdy korzystam z kernela 5.4.XX.
Wydaje mi się, że gdy korzystam z alternatywnego kernela 4.19.XXX, to problemu nie ma.

Odblokowane na prośbę @majo, a przy okazji kilka uwag ode mnie - owoce ostatnich miesięcy.

  • Używam Xfce, stable, dwa jądra.
  • Początkowo podejrzewałem light-locker’a. Związek był, ale jego wyeliminowanie nie rozwiązało problemu.
  • Sprawdziłem różne kernel’e i reakcje były odmienne. Na 4.19 było OK, a na wyższej wersji nie (nie pamiętam dokładnie numeru). Taki stan nie utrzymał się jednak długo i 4.19 również zaczęło generować ten sam problem, co wyższe wersje.
  • Podejrzewałem, że być może locker (xsecurelock), który zastąpił standardowy z Xfce (czyli light-locker) dorzuca swoje trzy grosze. Ślepa uliczka.
  • Zainstalowałem własnościowe sterowniki do karty graficznej (nVidia). Reakcja była odmienna - zamiast czarnego ekranu (i zawieszonego systemu) pojawiła się mozaika pixeli. Ale i to nie trwało długo, zawieszenia powróciły.
  • Ponownie zszedłem do kernel’a 4.19. Zawieszeń nie było, ale czerń owszem. System żył i dawał się zamknąć (fizyczny włącznik skonfigurowany na shutdown systemu). Przy pomocy paru czarodziejskich operacji udawało mi się odzyskiwać kontrolę nad ekranem, choć musiałem odświeżać dekoracje okna i tapetę. Czarodziejskie, bo wykonywałem je po omacku, na ślepo (nie pamiętam w jaki sposób doszedłem do tej pokręconej procedury i po czym byłem, że na to wpadłem):
    – odblokowanie ekranu (wpisanie hasła);
    – otwarcie okna terminala;
    – wydanie komendy odblokowującej przechodzenie pomiędzy konsolami (pakiet physlock);
    – przejście na pierwszą konsolę (Ctrl+Alt+F1), co skutkowało komunikatem o braku sygnału z karty graficznej;
    – powrót na konsolę no.7 (Ctrl+Alt+F7) - yes! yes! yes!
  • Wtedy (no właśnie, dlaczego tak późno?) pomyślałem, że może spróbuję bez physlock. Początkowo skrypt blokujący ekran i usypiający system, wzbogaciłem o wyłączenie physlock’a i … bingo. Wyłączyłem go na stałe. Działa, przynajmniej w przypadku jądra 4.19. Wersja 5.4 zwiesza.

Obecnie testuję temat statystycznie, sprawdzam stabilność rozwiązania w czasie i okolicznościach (uśpienie z ręki i z ‘automatu’). Konfiguracja aktualna:

  • kernel 4.19 (GRUB skonfigurowany w taki sposób, aby z automatu startował z jądrem 4.19, a nie domyślnym, czyli nowszym 5.4);
  • sterowniki do karty graficznej własnościowe;
  • blokada przechodzenia pomiędzy konsolami zdjęta (komputer stacjonarny, fizycznie bezpieczny, więc nie mam przeciwwskazań);
  • blokada ekranu (hasło) realizowana przez xsecurelock.

Przy takim komplecie j.w., wszystko gra: po wstaniu z uśpienia, pojawia się komunikat z prośbą o hasło, po wpisaniu którego zostaje przywrócony prawidłowy ekran i prawidłowo działający system. Póki co.

U mnie sytuacja wygląda tak:

  • kernel 4.19 (chyba bez problemów - ale to jeszcze zweryfikuję) lub 5.4 (z problemami);
  • sterowniki do karty graficznej - “free”: xf86-video-intel
  • blokada przechodzenia pomiędzy konsolami zdjęta (komputer stacjonarny, fizycznie bezpieczny, więc nie mam przeciwwskazań);
  • blokada ekranu (hasło): realizowana “ręcznie” przez komendę light-locker-command -l
  • automatyczne wygaszenie ekranu - zgodnie z ustawieniami Menedżera Zasilania ( xfce4-power-manager ) > zakładka: Ekran/Zarządzanie zasilaniem ekranu: po N minutach bezczynności.

Wspólnym mianownikiem naszych ustawień z problemami jest kernel 5.4.
Dodając do tego zbyt duże zużycie RAM pod kernelem 5.4, dojrzewam do decyzji, aby przełączyć się na stałe na kernel 4.19 (który ciągle jest najnowszym z “polecanych” kerneli).

Edit:
Niestety, ale z kernelem 4.19 też pojawia się ten problem (choć nie zawsze).
Chyba spróbuję ustawienia xsecurelock. Może u mnie też będzie OK.

Edit2:
Z kernelem 4.19:

  • problem nie pojawia się po ręcznym uruchomieniu blokady ekranu komendą light-locker-command -l
  • problem pojawia się po automatycznym wygaszenie ekranu (po okresie bezczynności - zgodnie z ustawieniami Menedżera Zasilania).

Wyrzuciłem light-locker’a, bo nie udało mi się (od wielu miesięcy - problem pojawił się w trakcie ostatnich zmian w Xfce) uzyskać prawidłowego działania, ani dojść do przyczyny problemu. Używam xsecurelock, ale testowałem - z powodzeniem - również inne locker’y.

Wydaje mi się, że u mnie light-locker nie stanowi problemu (przynajmniej po ręcznym uruchomieniu blokady ekranu).
Problemy pojawiają się gdy działa xfce4-power-manager, z ustawieniami jak poniżej, gdzie, jak mi się wydaje, nie powinno dochodzić do aktywacji light-locker’a.
2020-04-03_121406
2020-04-03_121432

Edit:
Wykonałem serię testów i wychodzi mi, że light-locker działa poprawnie z każdym kernelem, a problem jest generowany przez błąd w xfce4-power-manager.
Okazało się, że wygaszanie ekranu ciągle działa w sytuacji wyłączenia opcji Zarządzanie zasilaniem ekranu w zakładce Ekran (choć zgodnie z takimi ustawieniami nie powinno działać).
I, o dziwo, w takiej konfiguracji (wykorzystując powyższy błąd) problem z zamrażaniem się ekranu po automatycznym wygaszenie ekranu nie występuje.

Będę to jeszcze weryfikował przez kilka dni i dam znać, gdy się to potwierdzi.

Natomiast gdy w zakładce Bezpieczeństwo ustawiłem parametr Automatycznie blokuj sesję na wartość Gdy wygaszacz jest aktywowany, to po automatycznym wygaszenie ekranu, wszystko działa tak, jak u kolegi @azja, tj. po podaniu hasła ekran jest odblokowywany (co potwierdza, że light-locker jest OK).

@majo, pokaż jeszcze zakładkę ‘System’.


Ważne uzupełnienie informacji, nt. mojej obecnej konfiguracji:
oprócz tego, że pozbyłem się light-locker’a, to również odinstalowałem xfce4-screensaver.

Zakładka “System”:
2020-04-05_213654

A zakładka “Ekran” wygląda obecnie tak:
2020-04-05_214010

I nic się nie zamraża po wygaszeniu.

Ja też nie korzystam (i nie mam) z żadnego screesaver’a.

Edit:
Coś jednak jest nie tak z kernelem 5.4.x. Przez kilka dni problem z tego wątku nie pojawiał się z tym kernelem, a dziś dwa razy (więc to nie przypadek) go zanotowałem.

Przełączam się z powrotem na 4.9.x i zobaczę jak tu będzie. Na razie (po testach przy szybkim wygaszeniu - po 1 min i pozostałych ustawieniach, jak powyżej) wszystko jest OK.

Edit2:
Niestety, z kernelem 4.9.x też z powrotem pojawił się problem.

Zastanawiając się dlaczego przez weekend problemów nie było a obecnie są, przyszło mi do głowy, że problem może tkwić w innej aplikacji, która obecnie jest używana, a nie była przez weekend.
Mam tu dwa typy i spróbuje to jakość przetestować: wine i Java.

Edit3: (pon. 6-4, ok g.23:00; robi się mały dreszczowiec :slight_smile: )
Wyłączałem po kolei poszczególne zainstalowane aplikacje (, które działały, gdy były problemy) i problemy były także bez nich, co sugeruje, że raczej nie one generują problem.
Gdy już wszystko wyłączyłem i został sam system, problemy też były.

Po przeładowaniu systemu i uruchomieniu wszystkich aplikacji, które wcześniej były uruchomione, gdy były problemy z “zamrażaniem”, tym razem problemów NIE ma. Co potwierdza wcześniejszą hipotezę, że to nie te uruchamiane aplikacje generują ten problem.

Drążąc dalej temat, skojarzyłem, że w ciągu dnia miały miejsca 2 aktualizacje systemu, co być może jest nowym tropem w wyjaśnieniu tej “zagadki”.

Edit4: (wt, 7-04, g.8.30)
Pojawiła się nowa wskazówka, która wprowadza totalną niewiadomą, odnośnie przyczyn problemu :hot_face:

  • Był restart systemu.
  • Ustawiłem - testowo - szybki czas wygaszania - po 1 min.
  • Uruchomiłem wszystkie zwyczajowe aplikacje.
  • Początkowo (kilka razy) wszystko było OK po powrotach z wygaszenia.
  • W międzyczasie nie było żadnej aktualizacji systemu.
  • O godz. 7:43 pojawił się ponownie ten problem.
  • Później (kilka razy) zawsze po powrotach z wygaszenia problem się pojawiał.

Log systemowy pokazuje, że wcześniej nie było chyba żadnych istotnych błędów. Pro forma podaje je (Error’y) poniżej:

kwi 07 06:37:51 pcn ntpd[580]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
kwi 07 06:37:51 pcn ntpd[580]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
kwi 07 06:37:51 pcn systemd[1]: Started Network Time Service.
...
kwi 07 06:39:21 pcn msm_notifier[705]: error: failed to get installed kernels
kwi 07 06:39:21 pcn msm_notifier[705]: QProcess: Destroyed while process ("pacman") is still running.

Ostatnie minuty z logu wyglądają tak:

kwi 07 07:39:11 pcn kernel: perf: interrupt took too long (3136 > 3130), lowering kernel.perf_event_max_sample_rate to 63700
kwi 07 07:43:11 pcn systemd[1]: Started Getty on tty6.
kwi 07 07:43:11 pcn audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=getty@tty6 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
kwi 07 07:43:11 pcn kernel: audit: type=1130 audit(1586238191.522:91): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=getty@tty6 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
kwi 07 08:00:17 pcn kernel: perf: interrupt took too long (3925 > 3920), lowering kernel.perf_event_max_sample_rate to 50900

Być może poniższy zapis mówi o przyczynie(?):
kwi 07 07:39:11 pcn kernel: perf: interrupt took too long (3136 > 3130), lowering kernel.perf_event_max_sample_rate to 63700

Podobny zapis widać o godz. 8:00:17 - wtedy też pojawił się ten problem.

Edit5: (wt, 7-04, g.16:00)
Jednak powyższy zapis raczej nie generuje tego problemu, gdyż miałem kilka kolejnych tego typu problemów i zapis ten już się nie pojawiał w logu.

Spróbuję jeszcze odinstalować light-locker’a (choć mi nie wadzi). A nuż coś to pomoże.

Edit6: (śr, 8-04, g.9:30)
Po serii wczorajszych prób, dających przedziwne rezultaty, które podejrzewam, wynikają z błędów w xfce4-power-manager, odinstalowałem ten pakiet.
Zamiennie, zainstalowałem xfce4-screensaver do automatycznego wygaszania ekranu “ciemnym ekranem”.
Do ręcznego wygaszania stosuję komendę light-locker-command -l

Po restarcie systemu, jak na razie, wszystko działa poprawnie - bez “zamrażania”.

Edit7: (czw, 9-04, g.12:10)
Wczoraj, przez połowę dnia, zestaw: xfce4-screensaver + light-locker działał poprawnie.
Jednak w pewnym momencie problem się pojawił i potem występował już zawsze. W poprzednio testowanych zestawach też było podobnie, tj. najpierw wszystko działało poprawnie, a potem, gdy pojawiło się pierwsze “zamrożenie” ekranu, występowało ono już zawsze - do końca aktywnej sesji.

Znalazłem natomiast zgłoszenie bardzo podobnego bug’a dla light-locker’a z kwietnia 2019, które ciągle figuruje jako otwarte. Co potwierdza spostrzeżenia @azja odnośnie tego pakietu.

W konsekwencji odinstalowałam ten podejrzany pakiet i obecnie testuję tylko automatyczne wygaszanie z xfce4-screensaver. Jak na razie jest OK.

Od kilku aktualizacji nie mam już problemów z wychodzeniem z uśpienia - ani na kernel’u 4.19, ani na 5.4. Moja obecna konfiguracja:

  • własnościowe driver’y do karty graficznej (nVidia);
  • light-locker odinstalowany;
  • xfce4-screensaver odinstalowany;
  • ręczne usypianie:
$ xsecurelock -- systemctl suspend
  • automatyczne usypianie, po okresie bezczynności - bez blokady ekranu (wyłączona w konfiguracji Xfce). Taki sposób usypiania traktuję jako zabezpieczenie - na wypadek gdybym zapomniał, czy (nomen omen) zasnął i mam go ustawiony na dość długi czas. Poza tym, od wieków funkcjonuję z wykształconym zwyczajem ręcznego blokowania ekranu przed odejściem od komp’a.

Ponieważ stosuję zasadę mówiącą, że jeżeli coś działa, to nie zmieniaj tego, to póki co, traktuję problem jako zamknięty - mam działające rozwiązanie, z którego jestem zadowolony i zamierzam się go trzymać.

U mnie też od miesiąca wszystko działa poprawnie.
Wygląda na to, że problem leżał we ciągle niepoprawionym błędzie light-locker 'a (link 2 post wcześniej).

Moje aktualna i działające na wszystkich kernelach ustawienia, to:

  • sterowniki do karty graficznej - “free”: xf86-video-intel
  • odpowiednia konfiguracja DPMS (pokazałem w tym poście)
  • automatyczne wygaszanie za pomocą xfce4-screensaver
  • ręcznie wygaszanie: xdg-screensaver activate

Spotkałem się z różnymi nieprawidłowymi reakcjami, u siebie i u innych. Większość, mniej lub bardziej, ocierała się o light-locker’a, dlatego już na początku problemów odinstalowałem go i wracałem do niego czasem, w celach testowych.


Co ciekawe (miałem już wcześniej o tym napisać, ale umknęło), u mnie zarządzanie energią wygląda inaczej. Nie mam zakładki ‘Bezpieczeństwo’, a opcja ‘Zablokowanie ekranu po przejściu w stan wstrzymania’ jest na zakładce ‘System’:

power

Dlatego, że nie mam zainstalowanego xfce4-screensaver? Dlatego, że to maszyna stacjonarna, nie notebook? Z innego powodu? Nie mam sensownego pomysłu.

Też mam maszynę stacjonarną, a xfce4-screensaver wybrałem, gdyż najlepiej współpracuje z ręcznym wygaszaniem za pomocą xdg-screensaver activate .

Wcześniej w tym wątku pokazywałem screeny z xfce4-power-manager, którego w międzyczasie odinstalowałem i nie mam obecnie żadnego zamiennika (korzystam tylko z wyłączania zasilania ekranu poprzez opcje xfce4-screensaver - “czarny ekran” z odpowiednimi ustawieniami).
Czy aby na pewno to xfce4-power-manager?

Tak, a dokładniej xfce4-power-manager-settings, który jest jego częścią.