Broken suspend and backlight control -- kernel 4.8.13, drivers 375.20, GeForce 1060

I am using the Alienware 17r4 with the G-sync capable 120Hz display and the GeForce 1060 graphics card. I believe the Intel HD Graphics 530 is disabled in hardware, as there is no sign of it in the BIOS or in Windows or Linux. I am running Gentoo x86_64 with Linux kernel version 4.8.13 (though I have also tried versions 4.4.26, 4.8.11, and 4.8.12-r1) and using the NVIDIA driver version 375.20.

First, bringing the system out of suspend results in a completely broken system. On previous kernels, the system would come up and seem to be functional, but switching between open windows resulted in a black screen. Switching to a VTTY and back would sometimes fix the issue, however the VTTY was blank with patches of glitchy-looking pixels. Eventually either X would crash and reload, resulting in a working system, or it would freeze entirely and I would have to power off by holding the power button. On my most recent kernel, bringing the system out of sleep results in a black screen and an unresponsive system (e.g. keyboard LEDs do not respond to numlock/capslock). The dmesg output produced upon waking can be seen in my nvidia-bug-report.log.gz file from the output of ‘journalctl -b -1’. My computer went to sleep at around 2016-12-09T09:34:43-06:00 and woke at around 2016-12-09T09:36:03-06:00 (my local time).

Second, the monitor backlight intensity cannot be lowered from its maximum value. Pressing FN+F9/F10 results in an OSD brightness indicator which raises and lowers in response to the input, but the actual screen brightness does not change. Similarly, changing the brightness setting in the Plasma 5 power widget (which operates through powerdevil) has no effect. /sys/class/backlight has two entries, acpi_video0 and acpi_video1. Manually modifying the “brightness” file in either of these directories has no effect, however acpi_video1/brightness does update when the FN+F9/F10 keys are pressed (though not in response to the Plasma 5 power widget). I have attempted to install the third-party nvidiabl module (which you might be able to see in my nvidia-bug-report.log.gz), though it will not load as it fails to find compatible hardware. At no point have I managed to lower the brightness of the display from within Linux.
nvidia-bug-report.log.gz (115 KB)

I have upgraded to kernel version 4.8.14 and the issues persist. The backlight issue is unchanged, however the suspend problem seems to have possibly improved, though it is still unusable. It took well over a minute for my computer to come out of suspend, and my external monitor was disabled once it finally came back up. I attempted to re-enable my secondary monitor in KScreen after eventually managing to unlock the computer, but in doing so my primary display went black and the system became unresponsive. Pressing the power button once caused the computer to shut down cleanly after about a minute.

During the brief period that I was logged in after waking my computer, it seemed to be behaving mostly normally, however if I moved my cursor to the right of the display (where my secondary display is located), the entire screen scrolled to the right to display the SDDM unlock screen, which I was unable to interact with. I could push the screen back to the left by moving my cursor to the left edge of the screen.

Edit: I’m seeing the exact same behavior in kernel version 4.9.0.

These problems persist with NVidia driver 375.26, although another issue I didn’t mention has been solved: It used to be that if the screen turned off from idling, the only way to turn the backlight back on was to switch to a VTTY and back. That is no longer the case.

With a Clevo P651RE6-G, mounting an Nvidia 1060 under Ubuntu Gnome 16.10, I have the same problems:

  • bringing the system out of suspend results in a completely broken system;
  • screen does not turn on from idling (solved with driver 375.26).

As for the backlight control, I can adjust the brightness however the system always resets to maximum value at startup.

Are there any Pascal users (1060, 1070, 1080, or Titan X) with successful suspend/hibernate experiences? Or is suspend/hibernate broken for all Pascal GPUs in all current Linux distributions? I’m asking this because I started a similar thread about failing to wake from either suspend or hibernate in Pascal Titan X, and it looks like if all of us are having the same issue.

I’ve got a Clevo P650RP6-G, G-Sync, nvidia 1060, Gnome.

In my BIOS I can select “discrete” (only nvidia) or “mshybrid” (intel+nvidia).
In mshybrid mode, using the intel drivers I can control brigthness and the laptop is suspending. (I’m using bumblebee for nvidia)

In discrete mode, using only nvidia drivers, I’m loosing the brightness control and suspend.
Manually setting /sys/class/backlight/acpi_video0/brightness has no effect.

I would say that with nvidia drivers we don’t see the proper acpi interface. Or maybe the kernel is not looking at the proper location for the acpi ? Like it’s connecting to the intel’s related acpi not the nvidia’s one ?

For those with suspend problems: do you have more than one monitor attached? If so, does the problem go away if you suspend & resume with only one display attached?

I have a similar Clevo laptop that also has the brightness control problem. The good news is that one of my colleagues tracked it down to a new type of brightness control method used by these panels that wasn’t enabled in the Linux driver. He’s working on a fix to wire that up properly.

@olivarch

I do not have the option in my BIOS to switch between discrete and hybrid graphics. I believe this is because the display in this laptop supports G-sync, which is incompatible with Optimus.

I tend to agree with your assessment that the proprietary Nvidia drivers do not expose a proper ACPI interface. However, I was able to change my display brightness with the following command:

xrandr --output DP-0 --brightness 0.5

The output name probably varies from device to device. I also did some digging into why KDE’s PowerDevil widget was unable to set the brightness, as it supposedly uses xrandr (which works). Apparently, PowerDevil actually uses the XCB Randr API, which as far as I can tell xrandr does not use. This API does not work, even though xrandr does.

@aplattner

I do have a secondary display connected on DP-1. I will test suspending with this display disconnected and report back the results.

@aplattner

After disconnecting my external display and suspending, the exact same thing happens upon resume: Extreme input lag (>10 seconds) and an eventual complete freeze. Looking at journalctl after rebooting I see a lot of Xid 56 errors. Next, I tried suspending from a fresh boot without ever connecting my external display in the first place. This time it seemed to come out of suspend rather quickly, but there were a bunch of small graphical glitches. journalctl was again filled with new Xid 56 errors, and eventually my cursor disappeared. The computer was somewhat usable, but very unstable, and I ended up having to reboot.

Edit: I’ve attached the output of nvidia-bug-report.sh from after rebooting.
nvidia-bug-report.log.gz (115 KB)

I’m expiriencing exactly the same issues. (except I don’t have backlighht)
Linux Mint 18.1 xfce (xfwm4 from built from git), Nvidia 375.26 (tried also 378), kernel 4.4 / 4.8
What I’ve did:

  1. Booted up, ran sudo dmesg | grep Xid - it was clear

  2. Suspended PC and woke it up, greped dmesg - it was clear.

  3. Watched video on youtube, dmesg is still clear and I see my mouse cursor.

  4. Suspended PC and woke it up. dmseg is clear. Played video - I lose my mouse cursor and see Xid errors in dmesg! ( Immediately after video starts the cursor disappears and I see this errors in dmesg)

  5. To obtain mouse cursor back I close youtube, suspend PC and wake it up.

  6. Sometimes issue wasn’t reproduced, but restarting chrome reproduced it successfully

Instead of watching video you may run 3D game.

Moreover when I lose my mouse cursor and switch to TTY1 (ctrl alt f1) - The screen goes black and the system becomes unresponsive (but available via ssh). Sometimes I face freezes in Xorg session (e.g. running CS GO after suspend), Ctrl+Alt+Backspace helps, it kills current X.org session.

nvidia-bug-report.log.gz (105 KB)

@aplattner

The backlight issue olivarch is talking about isn’t related to the new aux_ch backlight mechanism some panels are using now. The model he has uses a panel with a traditional backlight mechanism that is well-supported in the existing NVIDIA Linux driver. If olivarch was using the Unity Desktop instead of GNOME, his backlight would probably work fine (after setting acpi_backlight=vendor in grub).

There are GNOME has troubles with backlight control when the NVIDIA binary driver is installed because GNOME doesn’t support the legacy xbacklight control mechanism (Unity still does), and the NVIDIA driver doesn’t currently support the /sys/class/backlight mechanism that olivarch describes.

I just upgraded to the Nvidia drivers version 378.13, and while the behavior has changed somewhat, suspend still does not work correctly. Now, my computer enters and leaves suspend relatively quickly and my secondary monitor is initialized correctly. However, upon coming out of suspend, I still have small graphical corruption and my mouse cursor still disappears after a few moments. Moving my mouse cursor results in many Xid 56 error messages in dmesg. Additionally, attempting to switch to a virtual terminal after waking from suspend gives me a solid black screen that I cannot get back from – I needed to hold the power button and reboot (even sysrq+REISUB did not work). I will attach my latest nvidia-bug-report.log.gz (why can’t I attach files until after I make the post?).
nvidia-bug-report.log.gz (120 KB)

Nvidia driver version 381.09 fixes the backlight issue, but suspend still causes the laptop to freeze, requiring a hard reset. I still get the same Xid 56 error message repeated many many times.

Driver version 375.66 fixes the suspend issue for me. All problems solved!