Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 693384 - VIDEO_CARDS="nvidia" (with sys-auth/elogind?) won't resume after suspend
Summary: VIDEO_CARDS="nvidia" (with sys-auth/elogind?) won't resume after suspend
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Jeroen Roovers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-03 08:54 UTC by Necktwi Ozfguah
Modified: 2020-08-04 17:08 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Necktwi Ozfguah 2019-09-03 08:54:14 UTC
This bug is same as https://bugs.gentoo.org/114213 but with elogind. The system resume when suspend is with `echo mem > /sys/power/state` works fine but if I suspend the system with `loginctl suspend`, resume gives black screen; I have to ssh xdm restart to get into gnome-shell.


```
$ emerge --info
Portage 2.3.69 (python 3.6.5-final-0, default/linux/amd64/17.0/desktop/gnome, gcc-8.3.0, glibc-2.29-r2, 4.19.66-gentoo x86_64)
=================================================================
System uname: Linux-4.19.66-gentoo-x86_64-Intel-R-_Core-TM-_i5-9600K_CPU_@_3.70GHz-with-gentoo-2.6
KiB Mem:    16135080 total,  11962144 free
KiB Swap:          0 total,         0 free
Head commit of repository gentoo: 75c5d9a19576231aa822810b0dd49a7870c68697

sh bash 4.4_p23-r1
ld GNU ld (Gentoo 2.32 p2) 2.32.0
distcc 3.3.2 x86_64-pc-linux-gnu [disabled]
app-shells/bash:          4.4_p23-r1::gentoo
dev-lang/perl:            5.28.2-r1::gentoo
dev-lang/python:          2.7.15::gentoo, 3.6.5::gentoo
dev-util/cmake:           3.14.6::gentoo
sys-apps/baselayout:      2.6-r1::gentoo
sys-apps/openrc:          0.41.2::gentoo
sys-apps/sandbox:         2.13::gentoo
sys-devel/autoconf:       2.13-r1::gentoo, 2.69-r4::gentoo
sys-devel/automake:       1.11.6-r3::gentoo, 1.16.1-r1::gentoo
sys-devel/binutils:       2.32-r1::gentoo
sys-devel/gcc:            8.3.0-r1::gentoo
sys-devel/gcc-config:     2.0::gentoo
sys-devel/libtool:        2.4.6-r3::gentoo
sys-devel/make:           4.2.1-r4::gentoo
sys-kernel/linux-headers: 4.19::gentoo (virtual/os-headers)
sys-libs/glibc:           2.29-r2::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: git
    sync-uri: https://github.com/gentoo/gentoo.git
    priority: -1000

crossdev
    location: /usr/local/portage-crossdev
    masters: gentoo
    priority: 10

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=native -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-march=native -O2 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-march=native -O2 -pipe"
GENTOO_MIRRORS="ftp://ftp.swin.edu.au/gentoo http://ftp.swin.edu.au/gentoo https://gentoo.c3sl.ufpr.br/ http://gentoo.c3sl.ufpr.br/ rsync://gentoo.c3sl.ufpr.br/gentoo/ http://gentoo.gossamerhost.com rsync://gentoo.gossamerhost.com/gentoo-distfiles/ ftp://mirrors.tera-byte.com/pub/gentoo http://gentoo.mirrors.tera-byte.com/ rsync://mirrors.tera-byte.com/gentoo ftp://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ https://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ http://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ https://mirrors.163.com/gentoo/ http://mirrors.163.com/gentoo/ https://mirrors.tuna.tsinghua.edu.cn/gentoo http://ftp.fi.muni.cz/pub/linux/gentoo/ ftp://ftp.fi.muni.cz/pub/linux/gentoo/ rsync://ftp.fi.muni.cz/pub/linux/gentoo/"
LANG="en_US.utf8"
LC_ALL="en_US.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac acl acpi alsa amd64 berkdb bluetooth branding bzip2 cairo cdda cdr cli colord crypt cups cxx dbus dri dts dvd dvdr eds egl elogind emboss encode evo exif fam flac fortran gdbm gif glamor gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk iconv icu introspection ipv6 jpeg lcms ldap libnotify libsecret libtirpc mad mng mp3 mp4 mpeg multilib nautilus ncurses networkmanager nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt5 readline sdl seccomp spell split-usr ssl startup-notification svg tcpd tiff truetype udev udisks unicode upower usb vorbis wayland wxwidgets x264 xattr xcb xml xv xvid zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" NETBEANS_MODULES="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" RUBY_TARGETS="ruby24 ruby25" USERLAND="GNU" VIDEO_CARDS="intel i965 nvidia vmware" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LINGUAS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
```
Comment 1 Necktwi Ozfguah 2019-09-03 12:43:11 UTC
I'm sorry, the related bug is https://bugs.gentoo.org/287710, not the one mentioned above.
Comment 2 Jeroen Roovers gentoo-dev 2019-09-04 05:54:23 UTC
It isn't even clear where the problem arises: could be a display driver or somewhere much higher up the software stack. Until you find the cause of the problem, there is no bug to fix. Please use our official support forums (IRC, mailing lists, web forums) to get support in fixing your problem, and file bug reports when you find actual bugs.
Comment 3 Necktwi Ozfguah 2019-09-04 16:00:25 UTC
Its not a bug! that's harsh! here is the system log when system is suspended with power button and when it is suspended with echo mem > /sys/power/state`

power button: https://pastebin.com/KUvVuam8
/sys/power/state: https://pastebin.com/SJkvM1q2
Comment 4 Mart Raudsepp gentoo-dev 2019-09-04 16:09:24 UTC
My understanding from IRC support channel, from where Necktwi comes from, is that the problem is with elogind too; so this is a elogind or related bug, not gnome-shell. Direct forced suspend via kernel file echo resumes fine; loginctl suspend doesn't resume fine.
Comment 5 Mart Raudsepp gentoo-dev 2019-09-04 20:08:28 UTC
I just said it's not a gnome-shell bug. Please wrangle properly...
Comment 6 Mart Raudsepp gentoo-dev 2019-09-05 05:21:36 UTC
sigh...
Comment 7 Necktwi Ozfguah 2019-09-12 18:13:26 UTC
I've merged gnome-light with VIDEO_CARDS="intel i965 nvidia vmware virtualbox". can this create any problem? vmware and virtualbox are to boot the gentoo physical partition from windows.
Comment 8 Necktwi Ozfguah 2019-10-08 14:27:20 UTC
But then `echo mem > /sys/power/state` works!
Comment 9 Sven Eden 2019-10-09 14:30:39 UTC
(In reply to Necktwi Ozfguah from comment #8)
> But then `echo mem > /sys/power/state` works!

And that's exactly what elogind does, it writes the chosen method (See /etc/elogind/logind.conf) into /sys/power/state.

The difference is, that elogind and systemd-login tell programs that are registered, that a suspension/hibernation is due, and that they have to prepare for it.
After wakeup, both tell these programs that the machine is resumed, and that they shall resume themselves, too.

One of the effect of this is network-manager to reconnect after resume.

If waking up generally works when done by hand (meaning: without messaging registered programs), then I daresay that something is not waking up properly.

The message is either "PrepareForSleep" or "PrepareForShutdown" via dbus through org.freedesktop.login1.Manager, and its either with the value 'true' before shutdown/hibernate/suspend, or 'false' after wakeup.

Something that should react on sending PrepareForSleep:false, doesn't as it should.
Comment 10 Sven Eden 2019-10-21 09:36:31 UTC
Another idea:

Is you whole system built with USE="-consolekit elogind -systemd" ?
Comment 11 Necktwi Ozfguah 2019-10-21 12:56:26 UTC
USE="wayland egl -tracker bluetooth nls vaapi"

I've isolated the issue. issue arises when I change VIDEO_CARDS="intel i965" to VIDEO_CARDS="intel i965 nvidia virtualbox vmware". and also i noticed that "gnome on Xorg" option is no longer available on gdm login screen; now it only got "gnome, Xsession, custom" options.

though i changed back to VIDEO_CARDS="intel i965" and did --newuse --deep @world, the issue won't go away and also there is no "gnome on Xorg" option in gdm login screen. 

and also now i got
```
!!! existing preserved libs:
>>> package: x11-drivers/nvidia-drivers-435.21
 *  - /usr/lib64/OpenCL/vendors/nvidia/libOpenCL.so.1
 *  - /usr/lib64/OpenCL/vendors/nvidia/libOpenCL.so.1.0.0
 *      used by /usr/lib64/libavfilter.so.7.40.101 (media-video/ffmpeg-4.1.3)
 *      used by /usr/lib64/libavutil.so.56.22.100 (media-video/ffmpeg-4.1.3)
Use emerge @preserved-rebuild to rebuild packages using these libraries
```
I don't understand why this message is shown even though the nvidia-drivers has been unmerged by the --newuse @world and it won't go away even if i do `emerge @preserver-rebuild`
Comment 12 Necktwi Ozfguah 2019-10-21 13:05:56 UTC
```
!!! existing preserved libs:
>>> package: x11-drivers/nvidia-drivers-435.21
```

is no more after i did `eselect opencl set biegnet`.

How to get back the "gnome on Xorg" option in gdm login screen?
Comment 13 Andreas Sturmlechner gentoo-dev 2019-10-21 13:06:35 UTC
this is not the Gnome on Xorg bug.
Comment 14 Necktwi Ozfguah 2019-10-21 13:15:47 UTC
but i lost the "gnome on Xorg" option only when this issue arised!

changing to VIDEO_CARDS="intel i965 nvidia virtualbox vmware" from VIDEO_CARDS="intel i965" caused this issue.
Comment 15 Andreas Sturmlechner gentoo-dev 2019-10-21 13:17:08 UTC
this bug is completely unrelated to gnome, please don't spam it further.
Comment 16 Necktwi Ozfguah 2019-10-22 15:49:28 UTC
With VIDEO_CARDS="intel i965" I tried changing profile from 17.1/desktop/gnome to 17.1 and emerge -ca. Then again changed profile to desktop/gnome and sudo emerge --deep --with-bdeps=y --changed-use --update --ask --verbose -k @world. but this didn't fix the issue.

https://pastebin.com/4Nws3qC3 is the system log from suspend to resume.
Comment 17 Necktwi Ozfguah 2019-10-22 18:39:04 UTC
I have installed a fresh Gentoo.
Suspend worked fine when VIDEO_CARDS="intel i965".
but stopped working when I used VIDEO_CARDS="intel i965 nvidia" and emerge --newuse
Comment 18 Necktwi Ozfguah 2019-10-24 01:57:35 UTC
blacklisting nvidia, nvidia_modeset, nvidia_drm fixed this issue.
Comment 19 Sven Eden 2019-11-27 19:13:07 UTC
(In reply to Necktwi Ozfguah from comment #17)
> I have installed a fresh Gentoo.
> Suspend worked fine when VIDEO_CARDS="intel i965".
> but stopped working when I used VIDEO_CARDS="intel i965 nvidia" and emerge
> --newuse

On my laptop I have:
VIDEO_CARDS="fbdev intel i965 nvidia"

On my desktop I have:
VIDEO_CARDS="fbdev nvidia"

Both resume fine from suspension, both from console and from Plasma started via SDDM.
I did not try out Wayland, though.

If "Gnome on Xorg" is missing, I suppose you are on Wayland? Is your system built with USE="wayland" activated?

I am asking, because all three of your logs show the same workflow... There is no hint about anything being "forgotten" when suspending using elogind.
...which would cause me to wonder anyway, as elogind does _nothing_ different.
Comment 20 Necktwi Ozfguah 2019-11-27 19:24:43 UTC
Yes, I have use="wayland" but on gdm login screen i choose "Gnome on Xorg" or it anyway falls back to Xorg due to nvidia card.
Comment 21 Necktwi Ozfguah 2019-12-02 13:02:31 UTC
I've removed wayland use flag and did emerge --newuse. it remerged nvidia-drivers along with other packages. But it didn't fix the issue. I also tried setting
options nvidia NVreg_DynamicPowerManagement=0x02
as per http://download.nvidia.com/XFree86/Linux-x86_64/435.17/README/dynamicpowermanagement.html but it didn't work.
Comment 22 Andreas Sturmlechner gentoo-dev 2019-12-02 13:12:09 UTC
(In reply to Necktwi Ozfguah from comment #17)
> Suspend worked fine when VIDEO_CARDS="intel i965".
> but stopped working when I used VIDEO_CARDS="intel i965 nvidia" and emerge
> --newuse
(In reply to Necktwi Ozfguah from comment #18)
> blacklisting nvidia, nvidia_modeset, nvidia_drm fixed this issue.
Per these informations I'm not sure what elogind is supposed to do in $summary.

Adding nvidia-drivers maintainer and keeping myself in CC for the time being.
Comment 23 Sven Eden 2019-12-05 07:57:42 UTC
(In reply to Necktwi Ozfguah from comment #18)
> blacklisting nvidia, nvidia_modeset, nvidia_drm fixed this issue.

Oh! Now I get it! You have a hybrid-laptop, right?

Yes, there are countless threads over several years that the nvidia-drivers cause trouble on resuming from suspend and/or hibernate.

I can replicate your problem easily by starting anything with primusrun/optirun and then suspending. Simple solution: Don't do that.

Maybe you could add hook scripts to unload the nvidia module(s) prior suspending/hibernating and reloading them after wakeup. But that would kill anything running using the nvidia drivers.

This *seems* to be a problem only for hybrid laptops without a MUX, like mine. On my nvidia-based desktop, suspend/hibernate work without any issue.

Absolutely not elogind related, and a long known problem with the proprietary nvidia drivers on linux.
Comment 24 Necktwi Ozfguah 2019-12-06 04:04:40 UTC
But remember **I was able to do a proper resume if I suspend with `echo mem > /sys/power/state`.**

Mine is not a laptop and i'm not running anything with primusrun/optirun. But recently I was able to offload render applications to Nvidia card.
Comment 25 Mi Yu 2019-12-24 06:27:07 UTC
I can reproduce this with nvidia-drivers and elogind with the same behavior: `echo mem > /sys/power/state` works, but `loginctl suspend` resumes to a blinking cursor and then to a black screen. I'm using a plain xorg-server setup with `exec bspwm` in xinitrc, so it should not be related to gnome-shell, but has to do either with nvidia-drivers or elogind. I am running a Quadro P2000 Mobile on my first-gen ThinkPad P1. My package versions:

```
$ emerge -pv gentoo-sources nvidia-drivers elogind xorg-server

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] sys-kernel/gentoo-sources-5.4.6:5.4.6::gentoo  USE="-build -experimental -symlink" 0 KiB
[ebuild   R    ] sys-auth/elogind-241.4::gentoo  USE="acl pam -debug -doc -policykit (-selinux)" 0 KiB
[ebuild   R    ] x11-base/xorg-server-1.20.6:0/1.20.6::gentoo  USE="elogind ipv6 libressl suid udev xorg xvfb -debug -dmx -doc -kdrive -libglvnd -minimal (-selinux) -static-libs -systemd -unwind -wayland -xcsecurity -xephyr -xnest" 0 KiB
[ebuild   R    ] x11-drivers/nvidia-drivers-440.44-r1:0/440::gentoo  USE="X acpi driver kms multilib tools -compat -gtk3 -libglvnd -static-libs -uvm -wayland" ABI_X86="(64) -32 (-x32)" 0 KiB

Total: 4 packages (4 reinstalls), Size of downloads: 0 KiB
```

Per NVIDIA's documentation [1], I've tried installing a suspend hook for elogind:

```
$ cat /lib64/elogind/system-sleep/20-nvidia 
#!/bin/sh
case "${1-}" in
    'pre')
        logger -t "elogind" -s "/usr/bin/nvidia-sleep.sh suspend"
        /usr/bin/nvidia-sleep.sh suspend
        logger -t "elogind" -s "/usr/bin/nvidia-sleep.sh: done"
        ;;

    'post')
        logger -t "elogind" -s "/usr/bin/nvidia-sleep.sh resume"
        /usr/bin/nvidia-sleep.sh resume
        logger -t "elogind" -s "/usr/bin/nvidia-sleep.sh: done"
        ;;

    *)
        exit 1
        ;;
esac
```

/usr/bin/nvidia-sleep.sh is unpacked from NVIDIA's official drivers, which essentially does `echo suspend > /proc/driver/nvidia/suspend`. From syslog I can verify that during both suspend and resume the script executes successfully, but I still have a black screen. `cat /sys/power/mem_sleep` shows that my suspend mode is "deep," which shouldn't affect the NVIDIA card.

I've also disabled all other power management tools except NVIDIA's built-in PRIME renderer offload [2]. I suspect this might have caused the issue, but a similar setup on Arch Linux seems to work fine. I'll test with a non-PRIME setup and/or systemd once I get the chance.

[1]: https://download.nvidia.com/XFree86/Linux-x86_64/440.44/README/powermanagement.html
[2]: https://download.nvidia.com/XFree86/Linux-x86_64/440.44/README/primerenderoffload.html
Comment 26 consus 2020-01-24 16:11:57 UTC
I can confirm this. Writing "mem" directly to /sys/class/power works great, "loginctl suspend" resumes to a black screen. However, if I run "loginctl suspend" without X (it does not matter if X is running or not, what matters is running loginctl from a tty) everything is great, no problems, resuming to a tty works, switching back to X works.

Hardware: Matebook X Pro (2018)
Kernel: 5.4.13 (vanilla-kernel-bin)

$ qlist -Iv | grep -E '/(vanilla-kernel|i3|elogind)'
sys-auth/elogind-241.4
sys-kernel/vanilla-kernel-bin-5.4.13
sys-kernel/vanilla-kernel-bin-5.4.10-r1
x11-wm/i3-gaps-4.16.1-r2

$ lsmod | grep -E '(intel|nvidia|nouveau)'
intel_rapl_msr         20480  0
intel_powerclamp       20480  0
intel_cstate           16384  0
intel_uncore          114688  0
intel_rapl_perf        16384  0
intel_wmi_thunderbolt    20480  0
intel_lpss_pci         20480  2
intel_lpss             16384  1 intel_lpss_pci
intel_pch_thermal      16384  0
intel_gtt              24576  1 i915
intel_rapl_common      28672  2 intel_rapl_msr,processor_thermal_device
intel_xhci_usb_role_switch    16384  0
intel_soc_dts_iosf     20480  1 processor_thermal_device

$ grep VIDEO /etc/portage/make.conf 
VIDEO_CARDS="intel i965"

$ grep modesetting /var/log/Xorg.0.log 
[   512.691] (==) Matched modesetting as autoconfigured driver 1
[   512.691] (II) LoadModule: "modesetting"
[   512.691] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so
[   512.691] (II) Module modesetting: vendor="X.Org Foundation"
[   512.691] (II) modesetting: Driver for Modesetting Kernel Drivers: kms

$ grep -E '\(EE|WW\)' /var/log/Xorg.0.log 
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   512.691] (WW) Warning, couldn't open module intel
[   512.691] (EE) Failed to load module "intel" (module does not exist, 0)
[   512.691] (WW) Warning, couldn't open module fbdev
[   512.691] (EE) Failed to load module "fbdev" (module does not exist, 0)
[   512.691] (WW) Warning, couldn't open module vesa
[   512.691] (EE) Failed to load module "vesa" (module does not exist, 0)
Comment 27 consus 2020-01-24 16:40:51 UTC
Also keyboard is not working, so I believe this is actually a Xorg bug. If I press "power" button long enough X is terminated, and console is shown to me with usual OpenRC stuff about shutting down. And keyboard is working again.
Comment 28 nicky12801 2020-05-22 10:55:54 UTC
Got it to work by putting this into /lib64/elogind/system-sleep/20-nvidia:

```
#!/bin/sh
case "${1-}" in
    'pre')
	chvt 63
	echo "suspend" > /proc/driver/nvidia/suspend
        ;;

    'post')
	echo "resume" > /proc/driver/nvidia/suspend
        ;;
    *)
        exit 1
        ;;
esac
```

This does almost everything that calling nvidia-sleep.sh would do, except restoring the previous TTY.

For whatever reason, suspending Nvidia (by writing to /proc/driver/nvidia/suspend) cannot be done while X is on the current TTY. So nvidia-sleep.sh first switches to TTY #63, which works fine. When resuming, however, it then tries to switch back to whatever TTY X was on, which freezes the system (I have no idea why). This is what my 20-nvidia script doesn't include.

After editing 20-nvidia, suspend/resume works fine, the only annoyance being that I have to manually ctrl-alt-F1 to get back to X.

I still have no clue why writing "mem" to /sys/power/state manually works fine, but calling `loginctl suspend` requires suspending the driver.

Anyway, I hope this helps someone and perhaps provides some more information to go on regarding the cause of the problem.
Comment 29 igel 2020-06-07 12:00:03 UTC
(In reply to nicky12801 from comment #28)
> Got it to work by putting this into /lib64/elogind/system-sleep/20-nvidia:
> #!/bin/sh
> case "${1-}" in
>     'pre')
> 	chvt 63
> 	echo "suspend" > /proc/driver/nvidia/suspend
>         ;;
> 
>     'post')
> 	echo "resume" > /proc/driver/nvidia/suspend
>         ;;
>     *)
>         exit 1
>         ;;
> esac

I had the same issue (even with nvidia* modules blacklisted) and this script fixed the issue for me. Might I suggest adding "(sleep 2 && chvt 1)&" in the 'post' case to avoid having to ctrl+alt+F1