Desktop computer with 2 displays
Leap 42.2
KDE 5
NVIDIA 375.26 driver
Wake from sleep when user logged into KDE: OK
Wake from sleep with no user logged in, computer sitting at login screen: Computer wakes but displays do not. Entering login password “blind” has no effect. Attempt to fall back to command-line does not work.
A little more information about your graphics chipset might be useful
/sbin/lspci -nnk| egrep 'VGA|3D|Display' -A3
or
/usr/sbin/hwinfo --gfxcard
If you turn compositing off prior to suspending does this help?
qdbus org.kde.KWin /Compositor org.kde.kwin.Compositing.suspend
qdbus org.kde.Solid.PowerManagement /org/freedesktop/PowerManagement Suspend
Compositing can be reinstated using
qdbus org.kde.KWin /Compositor org.kde.kwin.Compositing.resume
Ultimately, a bug report may be required here, and some useful info can be got from
qdbus org.kde.KWin /KWin supportInformation
FWIW, I did find this recent bug report but it relates to a different Plasma 5 and kernel version. It may still be due to the NVIDIA driver stack though. Hopefully, others can chime in with further advice.
I am suffering from the same issue.
Dell XPS 15 (9550) running Leap 42.2 (4.4.36-8-default kernel). Use case is slightly different for me as I tend to hibernate instead of suspend.
/sbin/lspci -nnk| egrep 'VGA|3D|Display' -A3
00:02.0 **VGA** compatible controller [0300]: Intel Corporation Skylake Integrated Graphics [8086:191b] (rev 06)
Subsystem: Dell Device [1028:06e4]
Kernel driver in use: i915
Kernel modules: i915
--
01:00.0 **3D** controller [0302]: NVIDIA Corporation GM107M [GeForce GTX 960M] [10de:139b] (rev a2)
Subsystem: Dell Device [1028:06e4]
Kernel driver in use: nouveau
Kernel modules: nouveau
hwinfo --gfxcard
09: PCI 02.0: 0300 VGA compatible controller (VGA)
[Created at pci.378]
Unique ID: _Znp.XoZP8Xodkf9
SysFS ID: /devices/pci0000:00/0000:00:02.0
SysFS BusID: 0000:00:02.0
Hardware Class: graphics card
Device Name: "Onboard IGD"
Model: "Intel HD Graphics 530"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x191b "HD Graphics 530"
SubVendor: pci 0x1028 "Dell"
SubDevice: pci 0x06e4
Revision: 0x06
Driver: "i915"
Driver Modules: "drm"
Memory Range: 0xdb000000-0xdbffffff (rw,non-prefetchable)
Memory Range: 0x70000000-0x7fffffff (ro,non-prefetchable)
I/O Ports: 0xf000-0xf03f (rw)
IRQ: 135 (363014 events)
Module Alias: "pci:v00008086d0000191Bsv00001028sd000006E4bc03sc00i00"
Driver Info #0:
Driver Status: i915 is active
Driver Activation Cmd: "modprobe i915"
Config Status: cfg=new, avail=yes, need=no, active=unknown
26: PCI 100.0: 0302 3D controller
[Created at pci.378]
Unique ID: VCu0.nrnNO2dCLqF
Parent ID: vSkL.l8qbncW1IE6
SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.0
SysFS BusID: 0000:01:00.0
Hardware Class: graphics card
Model: "nVidia GM107M [GeForce GTX 960M]"
Vendor: pci 0x10de "nVidia Corporation"
Device: pci 0x139b "GM107M [GeForce GTX 960M]"
SubVendor: pci 0x1028 "Dell"
SubDevice: pci 0x06e4
Revision: 0xa2
Driver: "nouveau"
Driver Modules: "drm"
Memory Range: 0xdc000000-0xdcffffff (rw,non-prefetchable)
Memory Range: 0xb0000000-0xbfffffff (ro,non-prefetchable)
Memory Range: 0xc0000000-0xc1ffffff (ro,non-prefetchable)
I/O Ports: 0xe000-0xefff (rw)
Memory Range: 0xdd000000-0xdd07ffff (ro,non-prefetchable,disabled)
IRQ: 126 (49 events)
Module Alias: "pci:v000010DEd0000139Bsv00001028sd000006E4bc03sc02i00"
Driver Info #0:
Driver Status: nouveau is active
Driver Activation Cmd: "modprobe nouveau"
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #8 (PCI bridge)
Primary display adapter: #9
Issue occurs with both the community built nvidia drivers as well as the driver downloaded and installed from nvidia directly.
I’ll try suspending composite later today and let you know.
Cheers ws
An Optimus system? You should start your own thread, as this may impact on the advice given?
Just looked up what an Optimus system is. Guess you may be correct. I’ll have a look at SDB:NVIDIA Bumblebee - openSUSE Wiki instead.
Cheers ws
It is a GTX960 by EVGA.
17: PCI 100.0: 0300 VGA compatible controller (VGA)
[Created at pci.378]
Unique ID: VCu0.uvNBC_QCyTC
Parent ID: vSkL.3rEhpzAE0V6
SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.0
SysFS BusID: 0000:01:00.0
Hardware Class: graphics card
Model: "nVidia GM206 [GeForce GTX 960]"
Vendor: pci 0x10de "nVidia Corporation"
Device: pci 0x1401 "GM206 [GeForce GTX 960]"
SubVendor: pci 0x3842 "eVga.com. Corp."
SubDevice: pci 0x2962
Revision: 0xa1
Driver: "nvidia"
Driver Modules: "nvidia"
Memory Range: 0xf6000000-0xf6ffffff (rw,non-prefetchable)
Memory Range: 0xe0000000-0xefffffff (ro,non-prefetchable)
Memory Range: 0xf0000000-0xf1ffffff (ro,non-prefetchable)
I/O Ports: 0xe000-0xefff (rw)
Memory Range: 0xf7000000-0xf707ffff (ro,non-prefetchable,disabled)
IRQ: 39 (261675 events)
Module Alias: "pci:v000010DEd00001401sv00003842sd00002962bc03sc00i00"
Driver Info #0:
Driver Status: nouveau is active
Driver Activation Cmd: "modprobe nouveau"
Driver Info #1:
Driver Status: nvidia_drm is active
Driver Activation Cmd: "modprobe nvidia_drm"
Driver Info #2:
Driver Status: nvidia is active
Driver Activation Cmd: "modprobe nvidia"
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #7 (PCI bridge)
I see in above, “Driver Status: nouveau is active”, which I was not expecting. I thought that the Nouveu driver was blacklisted with the installation of NVIDA’s driver. Is this a possible source of problems? Or am I mis-interpreting what* Driver Status* means?
I will experiment with the tests you suggested and return.
I see in above, “Driver Status: nouveau is active”, which I was not expecting. I thought that the Nouveu driver was blacklisted with the installation of NVIDA’s driver. Is this a possible source of problems? Or am I mis-interpreting what* Driver Status* means?
You can check with
lsmod|egrep 'nvidia|nouveau'
Indeed
I thought that the Nouveu driver was blacklisted with the installation of NVIDA’s driver.
It should be BUT blacklisting only applies to the boot sequence. So, if there is no nomodeset provision in place, then the nouveau kernel driver can still be manually or via other mechanism (such as through the X server loading the xorg nouveau driver, which then results in the nouveau kernel driver being loaded). See the nvidia driver doc: ftp://download.nvidia.com/XFree86/Linux-x86_64/375.26/README/commonproblems.html#nouveau
Is this a possible source of problems?
Likely
Or am I mis-interpreting what* Driver Status* means?
Don’t think so, but see Deano’s suggestion above
I will experiment with the tests you suggested and return.
After it fails to wake up, just shut the system off. Then on your next boot, grab the contents of your Xorg.0.log.old and paste them to susepaste and provide a link.
lsmod|egrep 'nvidia|nouveau'
Results in:
nvidia_drm 57344 1
nvidia_modeset 790528 6 nvidia_drm
nvidia 11960320 165 nvidia_modeset
nouveau 1597440 0
mxm_wmi 16384 1 nouveau
i2c_algo_bit 16384 1 nouveau
drm_kms_helper 155648 2 nouveau,nvidia_drm
ttm 106496 1 nouveau
drm 393216 6 ttm,drm_kms_helper,nouveau,nvidia_drm
wmi 16384 2 mxm_wmi,nouveau
video 40960 1 nouveau
button 16384 1 nouveau
I can confirm that file /etc/modprobe.d/disable-nouveau.conf exists and contains:
blacklist nouveau
options nouveau modeset=0
Using YAST, “Optional Kernel Command Line Parameter” contains:
showopts nouveau.blacklist=1 nomodeset vga=extended intel_pstate=disable
Was your initrd rebuilt after you installed the nvidia drivers?
I haven’t looked at nvidia xorg logs in quite a while so I can’t recall what the behaviour is exactly, but the
1070.010] (II) NOUVEAU driver for NVIDIA chipset families
entries make me think that the nouveau driver might have started to try to initialize. But maybe I’m mistaken. The other thing I see is the entries related to
1070.520] (--) NVIDIA(GPU-0)
That strikes me as a logging for a GPUDevice set up (i.e. two graphics adapters).
Are such entries above present in the log for a normal boot?
I did not touch initrd. I don’t know if the NVIDIA installer did.
That strikes me as a logging for a GPUDevice set up (i.e. two graphics adapters).
Note that I am running 2 displays, which might explain this.
Are such entries above present in the log for a normal boot?
Yes; both entries.
I would hope it would have. Rebuild it and see if there is any change (this is a long shot suggestion, but its a harmless and easy test).
Note that I am running 2 displays, which might explain this.
Do you mean Dispaly servers? or colloquially as in monitor/panel/display device? In any regard, neither case would account for the indexing of a second gpu (in the DISPLAY=:0 that Xorg.0.log). But again, I’m not really familiar with nvidia log output.
Yes; both entries.
Hmmm. I know you already posted the hwinfo output, but please provide:
/sbin/lspci -nnk | egrep 'VGA|3D|Display' -A3
I spotted the following flash across the screen during boot:
nouveau: unknown parameter ‘blacklist’ ignored
Could this be a clue?
Do you mean Dispaly servers? or colloquially as in monitor/panel/display device?
I mean hardware screens: one Dell U2410 and one Dell 2405 connected through cables to the outputs of the video card.
/sbin/lspci -nnk | egrep ‘VGA|3D|Display’ -A3
Outputs:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM206 [GeForce GTX 960] [10de:1401] (rev a1)
Subsystem: eVga.com. Corp. Device [3842:2962]
Kernel driver in use: nvidia
Kernel modules: nouveau, nvidia_drm, nvidia
You betcha.
Revisiting your xorg log:
1070.005] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.4.36-8-default root=UUID=676044b2-af35-4f1d-af01-63dd15a2a478 ro showopts nouveau.blacklist=1 nomodeset vga=extended intel_pstate=disable
/sbin/modinfo nouveau
No where in the parm section will you find a blacklist option. Ergo, you have set this up incorrectly. Revisit the nvidia documentation that I linked to earlier.
ls -la /etc/modprobe.d
And (for now) what do you have in the 50-blacklist.conf file?
Does your vga=extended even work? “vga=” is a boot parameter for the vesafb console framebuffer driver. I’d expect at best that this harmless, and, at worst, a potential for some trouble. I’d suggest removing it.
ls -la /etc/modprobe.d outputs:
drwxr-xr-x 2 root root 4096 Jan 16 08:23 .
drwxr-xr-x 137 root root 12288 Jan 19 17:31 ..
-rw-r--r-- 1 root root 3862 Oct 7 11:49 00-system.conf
-rw-r--r-- 1 root root 532 Nov 14 2012 10-unsupported-modules.conf
-rw-r--r-- 1 root root 181 Nov 30 01:55 50-alsa.conf
-rw-r--r-- 1 root root 5009 Oct 7 13:02 50-blacklist.conf
-rw-r--r-- 1 root root 128 Oct 7 22:18 50-bluetooth.conf
-rw-r--r-- 1 root root 33 Oct 7 13:11 50-ipw2200.conf
-rw-r--r-- 1 root root 34 Oct 7 13:11 50-iwl3945.conf
-rw-r--r-- 1 root root 18 Oct 7 13:11 50-prism54.conf
-rw-r--r-- 1 root root 8 Jan 16 08:23 50-yast.conf
-rw-r--r-- 1 root root 7 Jan 16 08:17 50-yast.conf.YaST2save
-rw-r--r-- 1 root root 47 Nov 22 2011 99-local.conf
-rw-r--r-- 1 root root 45 Jan 12 15:23 disable-nouveau.conf
50-blacklist.conf contains:
As the NVIDIA guide instructed, I did not edit 50-blacklist.conf and created disable-nouveau.conf with:
blacklist nouveau
options nouveau modeset=0
I don’t know where the vga=extended parameter came from. It’s in the “Optional Kernel Comand Line Parameter” field in the YAST Boot Loader tool. I assume it’s a SUSE default. I haven’t touched it. I will experiment with removing it.
My apologies. That looks right. Not sure why I went off track…tired…so very, very tired…Do make sure to rebuild your initrd though.
Actually, I just so happened to scroll above the
ftp://download.nvidia.com/XFree86/Linux-x86_64/375.26/README/commonproblems.html#nouveau section and saw that there is the following:
My log file contains a message like the following:
(WW) NVIDIA(GPU-0): Unable to enter interactive mode, because non-interactive
(WW) NVIDIA(GPU-0): mode has been previously requested. The most common
(WW) NVIDIA(GPU-0): cause is that a GPU compute application is currently
(WW) NVIDIA(GPU-0): running. Please see the README for details.
This indicates that the X driver was not able to put the GPU in interactive mode, because another program has requested non-interactive mode. The GPU watchdog will not run, and long-running GPU compute programs may cause the X server and OpenGL programs to hang. If you intend to run long-running GPU compute programs, set the Interactive option to “off” to disable interactive mode.
**I see a blank screen or an error message instead of a login screen or desktop session
**Installation or configuration problems may prevent t …
So, are you running any openCL/Cuda stuff?
I recant that … that nouveau.blacklist=1 does not look right.
Before going further, my question is why does this problem only occur from wake-from-sleep at the OpenSuse login screen?
The displays will wake from sleep with no issues when I am logged in to my KDE desktop.
If I logout and put the computer to sleep, the displays will fail to wake.
What’s the difference and why does only one circumstance fail?