Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 693384 - x11-drivers/nvidia-drivers: (with sys-auth/elogind?) won't resume after suspend
Summary: x11-drivers/nvidia-drivers: (with sys-auth/elogind?) won't resume after suspend
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 3 votes (vote)
Assignee: Ionen Wolkens
Depends on:
Reported: 2019-09-03 08:54 UTC by Necktwi Ozfguah
Modified: 2021-06-23 11:52 UTC (History)
18 users (show)

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

emerge --info (emerge_info.txt,7.86 KB, text/plain)
2021-06-22 19:41 UTC, wolfwood

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

    location: /usr/portage
    sync-type: git
    priority: -1000

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

CFLAGS="-march=native -O2 -pipe"
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"
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=" rsync:// rsync:// rsync:// rsync://"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
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"
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"
Comment 1 Necktwi Ozfguah 2019-09-03 12:43:11 UTC
I'm sorry, the related bug is, not the one mentioned above.
Comment 2 Jeroen Roovers (RETIRED) 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:
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
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/
 *  - /usr/lib64/OpenCL/vendors/nvidia/
 *      used by /usr/lib64/ (media-video/ffmpeg-4.1.3)
 *      used by /usr/lib64/ (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. 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 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 
case "${1-}" in
        logger -t "elogind" -s "/usr/bin/ suspend"
        /usr/bin/ suspend
        logger -t "elogind" -s "/usr/bin/ done"

        logger -t "elogind" -s "/usr/bin/ resume"
        /usr/bin/ resume
        logger -t "elogind" -s "/usr/bin/ done"

        exit 1

/usr/bin/ 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.

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

$ 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/
[   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:

case "${1-}" in
	chvt 63
	echo "suspend" > /proc/driver/nvidia/suspend

	echo "resume" > /proc/driver/nvidia/suspend
        exit 1

This does almost everything that calling 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 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
Comment 30 Mi Yu 2020-08-10 17:35:48 UTC
Thanks to the comments above, I got it working with /usr/bin/, which has the added benefit of detecting one's current vconsole number and restoring it upon resume. In /lib64/elogind/system-sleep/20-nvidia:

case "${1-}" in
        /usr/bin/ suspend
        /usr/bin/ resume &
        exit 1

The & sign in the 'post' case is odd: I don't understand why it should be there, but without it elogind still resumes to a blank console with a blinking cursor.

Is there any way we can move this bug forward? I see that the status of the bug is unconfirmed, but emerging a system with USE="elogind -systemd" and VIDEO_CARDS="nvidia" consistently reproduces this bug, regardless of kernel version or DE/WM. In nvidia-driver's pkg_postinst I also noticed this message:

> To enable nvidia sleep services under systemd, run these commands:
>	systemctl enable nvidia-suspend.service
>	systemctl enable nvidia-hibernate.service"
>	systemctl enable nvidia-resume.service"
> Set the NVreg_TemporaryFilePath kernel module parameter to a
> suitable path in case the default of /tmp does not work for you

It seems that, for feature parity under elogind, we would need to provide the same functionalities as these systemd services. Is there a way to add the appropriate elogind hook to the nvidia-drivers package?
Comment 31 Sven Eden 2020-09-01 06:04:54 UTC
(In reply to Mi Yu from comment #30)
> Thanks to the comments above, I got it working with
> /usr/bin/, which has the added benefit of detecting one's
> current vconsole number and restoring it upon resume. In
> /lib64/elogind/system-sleep/20-nvidia:
> #!/bin/sh
> case "${1-}" in
>     'pre')
>         /usr/bin/ suspend
>         ;;
>     'post')
>         /usr/bin/ resume &
>         ;;
>     *)
>         exit 1
>         ;;
> esac

I have just suggested a similar approach in

> It seems that, for feature parity under elogind, we would need to provide
> the same functionalities as these systemd services. Is there a way to add
> the appropriate elogind hook to the nvidia-drivers package?

Currently the nvidia-drivers package provides the systemd service files, correct? Maybe the package could have an "elogind" flag on its own, so it would provide a system-sleep hook script instead when enabled?

If you look at my comment behind that link above, you'll see that the approach, although it works, results in elogind logging an exit status of 2 from the script, and I don't know why.
So if anybody has an idea why this is happening, I'd appreciate any help I can get, as I would like to fix that before the v246-series of elogind hits RC status.

Thank you all for your (almost heavenly) patience!
Comment 32 bfrg 2020-09-01 17:39:48 UTC
I'm using the old 390.138-r4 nvidia-drivers because of an older graphics card (NVS 4200M). Unfortunately, this version doesn't seem to provide the script.
Comment 33 Ionen Wolkens gentoo-dev 2021-06-12 13:32:54 UTC
Would've helped if someone set the package name at some point.

Is this still an issue? Last I tried elogind it resumed fine from suspend without any special hooks, but I haven't tested it much or perhaps just doesn't apply to my hardware (i.e. I don't have a dual gpu laptop or similar)
Comment 34 Frederik Pfautsch 2021-06-12 13:57:09 UTC
(In reply to Ionen Wolkens from comment #33)
> Would've helped if someone set the package name at some point.
> Is this still an issue? Last I tried elogind it resumed fine from suspend
> without any special hooks, but I haven't tested it much or perhaps just
> doesn't apply to my hardware (i.e. I don't have a dual gpu laptop or similar)

For me (GTX 1650) it is still relevant. Tried several different things mentioned in the wiki and elsewhere (also the script from #28), nothing seems to work. If anybody is interested in specific logs/settings I am happy to provide them and try out stuff.

After resume I just get a blank screen (no cursor). Magic SysRq REIS followed by (login and) openrc (or reboot) usually helps but at that point my session is gone. Using GDM (gnome-shell) with XOrg. No hooks (empty /lib64/elogind/system-sleep/).

elgind-246.10-r1 (started at boot)

Basically followed
Nothing regarding nvidia in dmesg
Comment 35 Ionen Wolkens gentoo-dev 2021-06-12 23:55:23 UTC
Unfortunately if the script doesn't work for you then I don't think there's anything I can do, your case may be an nvidia upstream issue.

And as far as goes, it "shouldn't" be necessary with elogind's HandleNvidiaSleep option, so there's no sense in installing a hook at this point (it'd conflict if anything).

Do verify that you have NVreg_PreserveVideoMemoryAllocations set to 0 in /etc/modprobe.d/nvidia.conf as =1 tend to cause issues (your mileage may vary).

I believe original issue is technically fixed but I'll leave this bug open as reference for now. If someone that still has issues has sane solutions to suggest that could benefit from ebuild changes, I'm open to them.
Comment 36 wolfwood 2021-06-22 19:41:30 UTC
Created attachment 717717 [details]
emerge --info

I am also having this issue (echo mem > /sys/power/state works but loginctl suspend does not) on a desktop with an nvidia gpu.  I can ssh in after the failed resume but there is no amount of VT switching that brings X back.

I already had NVreg_PreserveVideoMemoryAllocations=0 in /etc/modprobe.d/nvidia.conf so that is not the issue.

it seems that the nvidia specific logic in elogind is not working as intended.
Comment 37 wolfwood 2021-06-22 20:38:05 UTC
additionally, sudo bash -c "/usr/bin/ suspend; echo mem > /sys/power/state; /usr/bin/ resume" works (ie doesn't break anything) but "/usr/bin/ suspend; loginctl suspend; /usr/bin/ resume" does not (neither does the /lib64/elogind/system-sleep/20-nvidia script which seems to either never have been called or have had a permission issue because it never created the directory /var/run/nvidia-sleep)

finally, and bizarrely, _none_ of the methods work if I am just at a console and have not started X11 yet.