Czarny ekran po wybudzeniu laptopa, brak jakiejkolwiek reakcji

Witam, mam dość uciążliwy problem, mianowicie:
Mam laptopa Huawei MateBook D14 z AMD, dual boot Manjaro + Windows. Po uśpieniu lub hibernacji laptopa, a konkretniej to przy wybudzeniu go, jedyne co widzę to czarny ekran. Nie działa kombinacja ctrl + alt + F2-F12, nie ma kursora, nic. Kompletny brak reakcji. Co można zrobić to przytrzymać przycisk przez 5 sekund i wymusić restart. W jaki sposób moge rozwiązać ten problem? Czytałem inne posty (na oficjalnym forum) z podobnymi problemami ale nie ma w nich rozwiązania problemu.

W pliku /etc/mkinitcpio.conf do modułów dodałem amdgpu

Inxi:

manjaro ~ $ inxi -Fxxxi
System:    Host: MateBook-D Kernel: 5.4.18-1-MANJARO x86_64 bits: 64 compiler: gcc v: 9.2.0 Desktop: KDE Plasma 5.17.5 
           tk: Qt 5.14.1 wm: kwin_x11 dm: SDDM Distro: Manjaro Linux 
Machine:   Type: Laptop System: HUAWEI product: KPL-W0X v: M1D serial: <root required> 
           Mobo: HUAWEI model: KPL-W0X-PCB v: M1D serial: <root required> UEFI: HUAWEI v: 1.19 date: 01/11/2019 
Battery:   ID-1: BAT1 charge: 28.9 Wh condition: 54.3/56.3 Wh (96%) volts: 7.7/7.6 model: DYNAPACK HB4593R1ECW type: Li-ion 
           serial: 4345 status: Discharging cycles: 103 
CPU:       Topology: Quad Core model: AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx bits: 64 type: MT MCP arch: Zen 
           L2 cache: 2048 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 31948 
           Speed: 1702 MHz min/max: 1600/2000 MHz boost: enabled Core speeds (MHz): 1: 1702 2: 1872 3: 1754 4: 1797 5: 2194 
           6: 1608 7: 1670 8: 1987 
Graphics:  Device-1: AMD Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] vendor: Huawei driver: amdgpu v: kernel 
           bus ID: 02:00.0 chip ID: 1002:15dd 
           Display: x11 server: X.Org 1.20.7 driver: amdgpu FAILED: ati unloaded: modesetting alternate: fbdev,vesa 
           compositor: kwin_x11 resolution: 1920x1080~60Hz 
           OpenGL: renderer: AMD RAVEN (DRM 3.35.0 5.4.18-1-MANJARO LLVM 9.0.1) v: 4.5 Mesa 19.3.3 direct render: Yes 
Audio:     Device-1: Advanced Micro Devices [AMD/ATI] Raven/Raven2/Fenghuang HDMI/DP Audio vendor: Huawei 
           driver: snd_hda_intel v: kernel bus ID: 02:00.1 chip ID: 1002:15de 
           Device-2: Advanced Micro Devices [AMD] Raven/Raven2/FireFlight/Renoir Audio Processor vendor: Huawei driver: N/A 
           bus ID: 02:00.5 chip ID: 1022:15e2 
           Device-3: Advanced Micro Devices [AMD] Family 17h HD Audio vendor: Huawei driver: snd_hda_intel v: kernel 
           bus ID: 02:00.6 chip ID: 1022:15e3 
           Sound Server: ALSA v: k5.4.18-1-MANJARO 
Network:   Device-1: Intel Wireless 8265 / 8275 driver: iwlwifi v: kernel bus ID: 01:00.0 chip ID: 8086:24fd 
           IF: wlp1s0 state: up mac: d0:c6:37:1b:a9:63 
           IP v4: 192.168.8.49/24 type: dynamic noprefixroute scope: global broadcast: 192.168.8.255 
           IP v6: fdac:75f:b9e2:1d00:46ee:5514:4627:4cf0/64 type: dynamic noprefixroute scope: global 
           IP v6: fe80::3f73:9460:946f:47b1/64 type: noprefixroute scope: link 
           WAN IP: 188.146.224.108 
Drives:    Local Storage: total: 447.14 GiB used: 21.78 GiB (4.9%) 
           ID-1: /dev/sda vendor: Western Digital model: WDS480G2G0B-00EPW0 size: 447.14 GiB speed: 6.0 Gb/s 
           serial: 1905AC803675 rev: 0000 scheme: GPT 
Partition: ID-1: / size: 33.39 GiB used: 16.63 GiB (49.8%) fs: ext4 dev: /dev/sda9 
           ID-2: /home size: 18.13 GiB used: 5.16 GiB (28.4%) fs: ext4 dev: /dev/sda10 
           ID-3: swap-1 size: 11.72 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda8 
Sensors:   System Temperatures: cpu: 39.2 C mobo: N/A gpu: amdgpu temp: 39 C 
           Fan Speeds (RPM): N/A 
Info:      Processes: 266 Uptime: 20m Memory: 6.76 GiB used: 2.16 GiB (32.0%) Init: systemd v: 242 Compilers: gcc: 9.2.0 
           Shell: bash v: 5.0.11 running in: konsole inxi: 3.0.37 
manjaro ~ $ 

Hibernacja i usypianie to dwie zupełnie różne rzeczy, choć pozornie robią to samo. Usypianie to zapisanie stanu systemu do RAM i odpowiednik polecenia systemctl suspend, natomiast hibernacja to zapisanie stanu systemu na dysk twardy, polecenie to systemctl hibernate. Aby móc zahibernować system musisz mieć SWAP, przy usypianiu nie jest on konieczny.

I niestety jest zła wiadomość. Nie ma prostego i jednego rozwiązania tego problemu, trzeba próbować i kombinować, aż w końcu coś zadziała. Na początek polecam artykuł na wiki Archa oraz naprawdę obszerny arykuł o naprawianiu Linuxowego usypiania i hibernacji.

Mam SWAP partycję o rozmiarze 12GB, RAMu mam 8GB więc z tym nie ma problemu.
Dzięki za odpowiedź, poczytam jeszcze i poszukam rozwiązań. Gdyby ktoś jeszcze miał jakieś propozycje to śmiało, w razie prośby o logi - nie ma problemu, doślę co potrzeba

Mam podobny problem, którego nie mam czasu rozwiązać, ale kilka spostrzeżeń, które być może będą pomocne:

  1. W moim przypadku, problem leżał w starym Xfce, a dokładniej w jego locker’ze (nie pamiętam nazwy). Tak mi się wydawało.
  2. Okazało się, że to tylko jeden element większego problemu, bo na kernel’u 4.19 było OK, a na 5.4 nie. Zacząłem podejrzewać, że nie jest, to kwestia moich specyficznych ustawień.
  3. W pewnym sensie podejrzenia te potwierdziły się, gdy zmieniłem stery do grafiki - z video-linux na nVidia. Problemy nadal występują, ale zamiast opisanych przez Ciebie objawów, mam działający system … prawie działający. Paroma magicznymi kombinacjami klawiszy odzyskuję obraz na ekranie. Obraz ten jest graficzną sieczką, którą likwiduję odświeżeniem motywu graficznego.

Trochę ostatnio posiedziałem przy konfiguracji hibernacji.

Zacznijmy od pytania: Ile powinniśmy mieć tego swapa? Wg. artykułu:

Jeśli używana jest hibernacja, rozmiar wymiany powinien być równy rozmiarowi RAM plus pierwiastek kwadratowy z rozmiaru RAM.

oraz pomocna tabelka:

Dlatego dla 8 GB RAM zrobiłem 11 GB swap.
Sprawdzamy czy w /etc/mkinitcpio linii HOOKS mamy wpis resume:

cat /etc/mkinitcpio.conf | grep HOOKS
HOOKS="base udev autodetect modconf block keyboard keymap resume filesystems"

Jeśli nie, to dopisujemy (zalecają gdzieś przy końcu linii) i wykonujemy

sudo mkinitcpio -P

Sprawdzamy UUID partycji swap:

lsblk -f | grep swap
sda5 swap   1    e84de737-27c2-4fa2-879b-a1cd21fb59a8       [SWAP]

Musimy dodać ten numer UUID do /etc/fstab i /etc/default/grub. U mnie będzie wyglądać to tak:

/etc/fstab:

UUID=e84de737-27c2-4fa2-879b-a1cd21fb59a8  none   swap defaults   0 0

/etc/default/grub linia GRUB_CMDLINE_LINUX_DEFAULT dodajemy resume=UUID=numer swap.
U mnie:

GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=e84de737-27c2-4fa2-879b-a1cd21fb59a8 udev.log_priority=3"

i przeładować gruba

sudo update-grub

Restart i po użyciu hibernacji wybudza się.
Jeśli nie mamy swapa to możemy zastosować swapfile. Opisów tworzenia swapfile jest mnóstwo w google.
Oczywiście jeśli posiadamy te wpisy to sprawdzamy tylko czy numer swap jest taki sam po komendzie lsblk -f, w fstab i grub.
A na koniec zacytuję naszego administratora;

Hibernacja? A po co to komu?

He he :slight_smile:

2 polubienia