Corrupted screen: "Six screens" Problem

For some users, using GeForce GT 100M's, the screen gets corrupted after X starts, divided into 6 sections with a resolution limited to 640x480.
The same problem has been recently reported with Quadro 2000 and hi-res displays.

To solve this problem, enable the Validation Mode NoTotalSizeCheck in section Device:

This error can occur for several different reasons, and the most common solution given for this error is to check for group/file permissions, which in almost every case is not the problem. The NVIDIA documentation does not talk in detail on what you should
do to correct this problem but there are a few things that have worked for some people. The problem can be a IRQ conflict with another device or bad routing by either the kernel or your BIOS.

First thing to try is to remove other video devices such as video capture cards and see if the problem goes away. If there are too many video processors on the same system it can lead into the kernel being unable to start them because of memory allocation problems with the video controller. In particular on systems with low video memory this can occur even if there is only one video processor. In such case you should find out the amount of your system's video memory (e.g. with lspci -v) and pass allocation parameters to the kernel, e.g. for a 32-bit kernel:

vmalloc=384M

If running a 64bit kernel, a driver defect can cause the NVIDIA module to fail initializing when IOMMU is on. Turning it off in the BIOS has been confirmed to work for some users. [1]User:Clickthem#nvidia module

Another thing to try is to change your BIOS IRQ routing from Operating system controlled to BIOS controlled or the other way around. The first one can be passed as a kernel parameter:

PCI=biosirq

The noacpi kernel parameter has also been suggested as a solution but since it disables ACPI completely it should be used with caution. Some hardware are easily damaged by overheating.

Note: The kernel parameters can be passed either through the kernel command line or the bootloader configuration file. See your bootloader Wiki page for more information.

Crashing in general

Try disabling RenderAccel in xorg.conf.

If Xorg outputs an error about "conflicting memory type" or "failed to allocate primary buffer: out of memory", or crashes with a "Signal 11" while using nvidia-96xx drivers, add nopat to your kernel parameters.

If the NVIDIA compiler complains about different versions of GCC between the current one and the one used for compiling the kernel, add in /etc/profile:

Or click on the Advanced button that is available on the X Server Display Configuration menu option. Select either Force Composition Pipeline or Force Full Composition Pipeline and click on Apply.

In order to make the change permanent, it must be added to the "Screen" section of the Xorg configuration file. When making this change, TripleBuffering should be enabled and AllowIndirectGLXProtocol should be disabled in the driver configuration as well. See example configuration below:

If you do not have an Xorg configuration file, you can create one for your present hardware using nvidia-xconfig (see NVIDIA#Automatic configuration) and move it from /etc/X11/xorg.conf to the preferred location /etc/X11/xorg.conf.d/20-nvidia.conf.

Note: Many of the configuration options produced in 20-nvidia.conf by using nvidia-xconfig are set automatically by the driver and are not needed. To only use this file for enabling composition pipeline, only the section "Screen" containing lines with values for Identifier and Option are necessary. Other sections may be removed from this file.

Multi-monitor

For multi-monitor setup you will need to specify ForceCompositionPipeline=On for each display. For example:

The above line is for two 3840x2160 monitors connected to DP-2 and DP-4. You will need to read the correct CurrentMetaMode by exporting xorg.conf and append ForceCompositionPipeline to each of your displays. Setting ForceCompositionPipeline only affects the targeted display.

Tip: Multi monitor setups using different model monitors may have slightly different refresh rates. If vsync is enabled by the driver it will sync to only one of these refresh rates which can cause the appearance of screen tearing on incorrectly synced monitors. Select to sync the display device which is the primarily used monitor as others will not sync properly. This is configurable in ~/.nvidia-settings-rc as 0/XVideoSyncToDisplayID= or by installing nvidia-settings and using the graphical configuration options.

To draw on the laptop panel, the Nvidia card writes to memory used by the Intel card, which then displays it on the screen. This is "Prime". Getting the two cards synced to avoid tearing needs Prime Sync, and to do that Nvidia driver needs to operate in kernel mode setting, which it does not by default.

Avoid screen tearing in KDE (KWin)

The problem is caused by incorrect assumption by the KDE devs about the behaviour of glXSwapBuffers and should be fixed in Plasma 5.12, Plasma 5.15, Plasma 5.16[2]. Additionally, NVIDIA#DRM kernel mode setting may be required.

Legacy solutions

For posterity, these are the legacy workarounds. Do not apply both workarounds because this may lead to high CPU load [3].

1. GL threads

Set GL threads to sleep by exporting __GL_YIELD="USLEEP" to just kwin_x11. Unlike setting up a global environment variable, this affects only KWin. It should also have the advantage over other workarounds, like forcing triple buffering or forcing composition pipeline in the driver, that it doesn't introduce additional stuttering when scrolling in Firefox or moving windows.

The script can be executed automatically at login with an autostart script:

~/.config/autostart-scripts/kwin.sh

#!/bin/bash
(sleep 2s && __GL_YIELD="USLEEP" kwin_x11 --replace)

Flag the script as executable.

The sleep argument helps to prevent issues when KWin is restarted/hanging after logging in, you might need to increase this time.

...
NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:139b)
NVRM: installed in this system is not supported by the 370.28
NVRM: NVIDIA Linux driver release. Please see 'Appendix
NVRM: A - Supported NVIDIA GPU Products' in this release's
NVRM: README, available on the Linux driver download page
NVRM: at www.nvidia.com.
...

This problem is caused by bad commits pertaining to PCIe power management in the Linux Kernel (as documented in this NVIDIA DevTalk thread).

The workaround is to add pcie_port_pm=off to your kernel parameters. Note that this disables PCIe power management for all devices.

Poor performance after resuming from suspend

If you are getting poor performance after resuming from suspend, you need to register the nvidia kernel module with the ACPI subsystem. This can be done by loading the nvidia module with the NVreg_RegisterForACPIEvents=1 NVreg_EnableMSI=1 options.

CPU spikes with 400 series cards

If you are experiencing intermittent CPU spikes with a 400 series card, it may be caused by PowerMizer constantly changing the GPU's clock frequency. Switching PowerMizer's setting from Adaptive to Performance, add the following to the Device section of your Xorg configuration:

Full system freeze or crashes when using Flash

If you experience occasional full system freezes using Flash, a possible workaround is to disable Hardware Acceleration:

/etc/adobe/mms.cfg

EnableLinuxHWVideoDecode=0

Or, if you want to keep Hardware acceleration enabled but allowing a higher chance of screen tearing, you may try to before starting a browser:

export VDPAU_NVIDIA_NO_OVERLAY=1

Laptops: X hangs on login/out, worked around with Ctrl+Alt+Backspace

If, while using the legacy NVIDIA drivers, Xorg hangs on login and logout (particularly with an odd screen split into two black and white/gray pieces), but logging in is still possible via Ctrl+Alt+Backspace (or whatever the new "kill X" key binding is), try adding this in /etc/modprobe.d/modprobe.conf:

options nvidia NVreg_Mobile=1

One user had luck with this instead, but it makes performance drop significantly for others:

Screen(s) found, but none have a usable configuration

Sometimes NVIDIA and X have trouble finding the active screen. If your graphics card has multiple outputs try plugging your monitor into the other ones. On a laptop it may be because your graphics card has VGA/TV out. Xorg.0.log will provide more info.

Another thing to try is adding invalid "ConnectedMonitor" Option to Section "Device"
to force Xorg throws error and shows you how correct it.
Here
more about ConnectedMonitor setting.

After re-run X see Xorg.0.log to get valid CRT-x,DFP-x,TV-x values.

nvidia-xconfig --query-gpu-info could be helpful.

Blackscreen at X startup / Machine poweroff at X shutdown

If you have installed an update of Nvidia and your screen stays black after launching Xorg, or if shutting down Xorg causes a machine poweroff, try the below workarounds:

You can also try to add the nvidia module directly to your mkinitcpio config file.

If the screen still stays black with both the rcutree.rcu_idle_gp_delay=1kernel parameter and the nvidia module directly in the mkinitcpio config file, try re-installing nvidia and nvidia-utils in that order, and finally reload the driver:

# modprobe nvidia

Backlight is not turning off in some occasions

By default, DPMS should turn off backlight with the timeouts set or by running xset. However, probably due to a bug in the proprietary Nvidia drivers the result is a blank screen with no powersaving whatsoever. To workaround it, until the bug has been fixed you can use the vbetool as root.

Driver 415: HardDPMS

Proprietary driver 415 includes a new feature called HardDPMS. This is reported by some users to solve the issues with suspending monitors connected over DisplayPort.
It is reported to become the default in a future driver version, but for now, the HardDPMS option can be set in the Device or Screen sections. For example:

HardDPMS will trigger on screensaver settings like BlankTime. The following ServerFlags will set your monitor(s) to suspend after 10 minutes of inactivity:

/etc/X11/xorg.conf.d/20-nvidia.conf

Section "ServerFlags"
Option "BlankTime" "10"
EndSection

Xorg fails to load or Red Screen of Death

If you get a red screen and use GRUB, disable the GRUB framebuffer by editing /etc/default/grub and uncomment GRUB_TERMINAL_OUTPUT=console. For more information see GRUB/Tips and tricks#Disable framebuffer.

Black screen on systems with Intel integrated GPU

If you have an Intel CPU with an integrated GPU (e.g. Intel HD 4000) and have installed the nvidia package, you may experience a black screen on boot, when changing virtual terminal, or when exiting an X session. This may be caused by a conflict between the graphics modules. This is solved by blacklisting the Intel GPU modules. Create the file /etc/modprobe.d/blacklist.conf and prevent the i915 and intel_agp modules from loading on boot:

/etc/modprobe.d/blacklist.conf

install i915 /usr/bin/false
install intel_agp /usr/bin/false

No audio over HDMI

Sometimes nvidia HDMI audio devices are not shown when you do

aplay -l

For whatever reason on some new machines, the audio chip on the nvidia GPU is disabled at boot. Read more here and here

You need to reload the nvidia device with audio enabled. In order to do that make sure that your GPU is on (in case of laptops/Bumblebee) and that you are not running X on it, because it's going to reset:

Note: lspci output is in hex format, but in config files the BusID's are in decimal format.

Xorg fails during boot, but otherwise starts fine

On very fast booting systems, systemd may attempt to start the display manager before the NVIDIA driver has fully initialized. You will see a message like the following in your logs only when Xorg runs during boot.

If you have additional cards needed for the desktop then list them in Wants and After seperated by spaces.

xrandr BadMatch

If you are trying to configure a WQHD monitor such as DELL U2515H using xrandr and xrandr --addmode gives you the error X Error of failed request: BadMatch, it might be because the proprietary NVIDIA driver clips the pixel clock maximum frequency of HDMI output to 225 MHz or lower. To set the monitor to maximum resolution you have to install nouveau drivers. You can force nouveau to use a specific pixel clock frequency by setting nouveau.hdmimhz=297 (or 330) in your Kernel parameters.

Alternatively, it may be that your monitor's EDID is incorrect. See #Override EDID.

Another reason could be that per default current NVidia drivers will only allow modes explicitly reported by EDID; but sometimes refresh rates and/or resolutions are desired which are not reported by the monitor (although the EDID information is correct; it's just that current NVidia drivers are too restrictive).

If this happens, you may want to add an option to /etc/X11/xorg.conf.d/ to allow non-EDID modes: