Project

General

Profile

Bug #3414

Black screen after suspend

nona - about 1 year ago - . Updated about 1 year ago.

Status:
info needed
Priority:
bug
Assignee:
-
% Done:

0%


Description

  • steps to reproduce:
    0. (consult dm-crypt/Encrypting an entire system)
    1. create a GPT partition table (fdisk /dev/sdX, where /dev/sdX is a drive not a partition; then set to GPT with g and create partitions as needed)
    2. encrypt a partition with LUKS ( cryptsetup luksFormat /dev/sdXY, where /dev/sdX is a drive, and /dev/sdXY is a partition on the drive )
    3. decrypt the partition ( cryptsetup luksOpen /dev/sdXY crypt )
    4. create a logical volume on the decrypted partition ( pvcreate /dev/mapper/crypt vgcreate mylvm /dev/mapper/crypt )
    5. create a swap partition ( lvcreate -L $size mylvm -n myswap ) on the logical volume (besides your system)
    6. install GRUB on your system and install the boot loader ( grub-install --target=i386-pc /dev/sdX )
    7. get the UUID of your logical swap partition ( blkid -s UUID -o value /dev/mylvm/myswap ; example output: xxx-xxx-xxx)
    8. add an entry with /dev/mylvm/myswap none swap sw 0 0 into /etc/fstab
    9. add resume to the hooks in /etc/mkinitcpio.conf
    10. add resume=UUID=xxx-xxx-xxx to /etc/default/grub into the GRUB_CMDLINE_LINUX (also add cryptdevice=UUID=yyy-yyy-yyy:crypt . With a LUKS1 partition for boot, add cryptkey=rootfs:/your_key too, and /your_key to FILES in /etc/mkinitcpio.conf )
    11. add nomodeset to /etc/default/grub into the GRUB_CMDLINE_LINUX
    12. install OpenRC and uninstall SystemD
    13. install LXDE or iceWM, reboot, login, close the lid
    14. open the lid to bring back from suspend
  • expected result:
    a GUI or some sort of prompt for a password
  • actual result:
    empty black screen (reminds me of the blue screen of death)
  • other
    tested with linux-libre, linux-libre-lts, linux-libre-hardened
    linux-libre 5.18.14-1
    linux-libre-api-headers 5.17.3_gnu-1
    linux-libre-hardened 5.18.12.hardened1-1
    linux-libre-headers 5.18.14-1
    linux-libre-lts 5.15.72-1

Files

lspci_and_logs.tar.gz (6.6 KB) lspci_and_logs.tar.gz hardware, logs, error messages nona, 2022-12-31 08:41 PM

History

#1

Updated by wael about 1 year ago

  • Status changed from unconfirmed to info needed
More information to debug is needed:
  1. What kind of system is this? I presume a laptop from the description, but what model?
  2. In case it is a system running non-OEM firmware, please state the version.
  3. Does the system wake up from sleep at all? (I.E.: Is it only that the screen is dark) or does it stay stuck in sleep?

If you manage to get the logs that would help debugging the issue quite immensely.

#2

Updated by anonymous about 1 year ago

I think need see video card information, information about using driver in part of suspend support. For example https://nouveau.freedesktop.org/FeatureMatrix.html. What GPU you have?

#3

Updated by nona about 1 year ago

Sorry, I forgot to add the logs. Here they are.

The system seems to wake up to a blank screen. I can push the "power-off" button once and it does shut down.

#4

Updated by bill-auger about 1 year ago

03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] [1002:15dd] (rev c4) (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Radeon Vega 8 Mobile [103c:83c6]

h-node has no listing for the graphics card; but that is probably not the problem

have you 'nonsystemd/polkit' installed?

$ pacman -Qs polkit

also, IIRC DMs can interfere with resume - lightdm has been rather flakey - if using a DM, you could try a different one, such as LXDM (or none, just `startx`)

if you are launching X as unprivileged user, you could also try `startx` as root, to see if you get the same behaviour

#5

Updated by nona about 1 year ago

bill-auger wrote:

h-node has no listing for the graphics card; but that is probably not the problem

Hopefully--really, really--that's not the case, but I have had so much trouble with this GPU (roll eyes). Also, I have nomodeset (as a reminder).

have you 'nonsystemd/polkit' installed?

pacman -Qs | grep nonsystemd

local/polkit 121-1.nonsystemd1

also, IIRC DMs can interfere with resume - lightdm has been rather flakey - if using a DM, you could try a different one, such as LXDM (or none, just `startx`)

LightDM and LXDM give the same result (besides closing the lid, I also tried with Suspend from the Log-out menu with the latter)

if you are launching X as unprivileged user, you could also try `startx` as root, to see if you get the same behaviour

Summary: does the same thing; now I am sure that it comes back, the screen just happens to be black (read below for details):

This was interesting: I don't have xterm, and I got an error when I tried to run startx (became root with su). While still in the terminal (the one after OpenRC and before any DM or startx), I decided to close the lid. The black screen was back when I opened it again, but then I typed echo "hello". After rebooting, I was able to see the command in /root/.bash_history.

I did a rc-service lxdm start and the Suspend option from the log-out menu did the same (as described above). Does this count as "`startx` as root"?

Secondly, I have scripts (.xinitrc, .bash_profile, .xserverrc) to launch the WM (window manager). At this point they were disabled. This means that I have also tried without a DM (display manager; also known as graphical login greeter).

Thank you very much.

#6

Updated by bill-auger about 1 year ago

maybe try different power managers now

# pacman -Ssq power-manager
gnome-power-manager
xfce4-power-manager
mate-power-manager
ukui-power-manager

sry i dont have much experience with laptops - my openrc system has no power manager installed - IIRC, there are some special requirements for mkinitcpio hooks ('suspend', 'resume', or similar), and those could be different for openrc vs systemd

openrc also had some special requirements of permission groups

$ groups

my openrc system's X user belongs to these system groups - IIRC, these were the wiki recommendation at one time

sys video storage disk optical audio

#7

Updated by nona about 1 year ago

Hi, bill. I've got progress. After doing the following, my screen and keyboard is frozen; after hitting the power button, there is a blinking underscore; hitting CTRL+ALT+F1 takes me back to my graphical desktop (I will be using the notation of Emac's Org):

#+begin_src bash :dir /sudo::/
echo 1 > /sys/power/pm_trace
echo s2idle > /sys/power/mem_sleep & echo freeze > /sys/power/state
#+end_src

For whomever is interested, this may also be useful

#+begin_src bash :dir /sudo::/
pacman -Rnucs acpi
#+end_src
/usr/lib/modules/5.18.14-gnu-1/build/Documentation/admin-guide/pm/suspend-flows.rst
/usr/lib/modules/5.18.14-gnu-1/build/Documentation/admin-guide/pm/sleep-states.rst
#+name: s2idle_sleep_states.rst
#+begin_quote
Suspend-to-Idle
...
It is always
supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration option is set.
#+end_quote
#+begin_quote
Standby
...
The set of devices that can wake up the system from this state usually is
reduced relative to :ref:`suspend-to-idle <s2idle>` {how do I know if my hardware is compatible?}
...
This state is supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration
option is set and the support for it is registered by the platform with the
core system suspend subsystem. On ACPI-based systems this state is mapped to
the S1 system state defined by ACPI. {how do I send that signal? get it into that state? /proc...?}
#+end_quote
#+begin_quote
Suspend-to-RAM
...
In particular, on ACPI-based
systems the kernel passes control to the platform firmware (BIOS) as the last
step during S2RAM transitions and that usually results in powering down some
more low-level components that are not directly controlled by the kernel. {is the BIOS the culprit?}
...
On ACPI-based systems S2RAM requires some minimal boot-strapping code in the
platform firmware to resume the system from it {does mkinitcpio have what it needs? is my hardware supported?}
...
The set of devices that can wake up the system from S2RAM usually is reduced
relative to :ref:`suspend-to-idle <s2idle>` and :ref:`standby <standby>` and it
may be necessary to rely on the platform for setting up the wakeup functionality
as appropriate. {how do I know if my hardware is compatible?}
...
S2RAM is supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration option
is set and the support for it is registered by the platform with the core system
suspend subsystem. On ACPI-based systems it is mapped to the S3 system state
defined by ACPI.
#+end_quote
#+begin_quote
Basic ``sysfs`` Interfaces for System Suspend and Hibernation
...
The power management ... provides ... a unified ``sysfs``
interface ... regardless of the underlying system architecture ...
located in the :file:`/sys/power/`
...
``state``
This file contains a list of strings representing sleep states supported
by the kernel. Writing one of these strings into it causes the kernel
to start a transition of the system into the sleep state represented by
that string.
... the "disk", "freeze" and "standby" strings represent the
:ref:`hibernation <hibernation>`, :ref:`suspend-to-idle <s2idle>` and
:ref:`standby <standby>` sleep states, respectively. The "mem" string
is interpreted in accordance with ... the ``mem_sleep`` file...
If the kernel does not support any system sleep states, this file is
not present.
#+end_quote
#+begin_src bash
cat /sys/power/state
#+end_src
#+caption: Should I remove these?
#+RESULTS:
: freeze mem
#+begin_quote
``mem_sleep``
The strings that may be present in this file are "s2idle", "shallow"
and "deep". The "s2idle" string always represents :ref:`suspend-to-idle
<s2idle>` and, by convention, "shallow" and "deep" represent
:ref:`standby <standby>` and :ref:`suspend-to-RAM <s2ram>`,
respectively.
#+end_quote
#+begin_src bash
cat /sys/power/mem_sleep
#+end_src
#+caption: It is going into s2idle ([[s2idle_sleep_states.rst]])
#+RESULTS:
: s2idle [deep]
#+begin_quote
According to the above, there are two ways to make the system go into the
:ref:`suspend-to-idle <s2idle>` state. The first one is to write "freeze"
directly to :file:`/sys/power/state`. The second one is to write "s2idle" to
:file:`/sys/power/mem_sleep` and then to write "mem" to
:file:`/sys/power/state`. Likewise, there are two ways to make the system go
into the :ref:`standby <standby>` state (the strings to write to the control
files in that case are "standby" or "shallow" and "mem", respectively) if that
state is supported by the platform. However, there is only one way to make the
system go into the :ref:`suspend-to-RAM <s2ram>` state (write "deep" into
:file:`/sys/power/mem_sleep` and "mem" into :file:`/sys/power/state`).
#+end_quote
#8

Updated by nona about 1 year ago

bill-auger wrote:

maybe try different power managers now

xfce4-power-manager also put the computer into suspend mode, and a black screen when resuming. It did this with and without

HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore

in /etc/elogind/logind.conf (https://forum.xfce.org/viewtopic.php?pid=52468#p52468 ; https://forum.artixlinux.org/index.php/topic,282.0.html )

Before installing xfce4-power-manager , this produces the reported error as well (black screen when resuming).
#+begin_src bash :dir /sudo::/
echo 1 > /sys/power/pm_trace
echo shallow > /sys/power/mem_sleep & echo mem > /sys/power/state
#+end_src

Screen is dark, power button blinks. Pressing the power button brings the computer back into a black screen.

sry i dont have much experience with laptops - my openrc system has no power manager installed - IIRC, there are some special requirements for mkinitcpio hooks ('suspend', 'resume', or similar), and those could be different for openrc vs systemd

I have resume in the hooks, but I'll have to check if more are needed.

openrc also had some special requirements of permission groups
[$ groups]

Yep, my user is part of the club

I am assuming that the commands above (echo shallow...) go directly to the kernel power management. Since (1) the s2idle does not turn off the screen and shallow does, and (2) the system is still operative with s2idle, I think that some how the screen is turned off, but not turned back on. A lingering question is how to make use of the pm_trace to debug.

Also available in: Atom PDF