https://wiki.archlinux.org/api.php?action=feedcontributions&user=Asamarin&feedformat=atomArchWiki - User contributions [en]2024-03-29T09:04:00ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=NVIDIA/Troubleshooting&diff=515057NVIDIA/Troubleshooting2018-03-27T14:46:31Z<p>Asamarin: Fix typo "</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[ja:NVIDIA/トラブルシューティング]]<br />
[[ru:NVIDIA/Troubleshooting]]<br />
== Corrupted screen: "Six screens" Problem ==<br />
<br />
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.<br />
The same problem has been recently reported with Quadro 2000 and hi-res displays.<br />
<br />
To solve this problem, enable the Validation Mode {{ic|NoTotalSizeCheck}} in section {{ic|Device}}:<br />
Section "Device"<br />
...<br />
Option "ModeValidation" "NoTotalSizeCheck"<br />
...<br />
EndSection<br />
<br />
== '/dev/nvidia0' input/output error ==<br />
<br />
{{Accuracy|Verify that the BIOS related suggestions work and are not coincidentally set while troubleshooting.|section='/dev/nvidia0' Input/Output error... suggested fixes}}<br />
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<br />
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.<br />
<br />
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 {{ic|lspci -v}}) and pass allocation parameters to the kernel, e.g. for a 32-bit kernel:<br />
vmalloc=384M<br />
<br />
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. [http://www.nvnews.net/vbulletin/showthread.php?s=68bb2fabadcb53b10b286aa42d13c5bc&t=159335][[User:Clickthem#nvidia module]]<br />
<br />
Another thing to try is to change your BIOS IRQ routing from {{ic|Operating system controlled}} to {{ic|BIOS controlled}} or the other way around. The first one can be passed as a kernel parameter:<br />
PCI=biosirq<br />
<br />
The {{ic|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.<br />
<br />
{{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.}}<br />
<br />
== Crashing in general ==<br />
<br />
* Try disabling {{ic|RenderAccel}} in xorg.conf.<br />
* If Xorg outputs an error about {{ic|"conflicting memory type"}} or {{ic|"failed to allocate primary buffer: out of memory"}}, or crashes with a "Signal 11" while using nvidia-96xx drivers, add {{ic|nopat}} to your [[kernel parameters]].<br />
* If the NVIDIA compiler complains about different versions of GCC between the current one and the one used for compiling the kernel, add in {{ic|/etc/profile}}:<br />
export IGNORE_CC_MISMATCH=1<br />
* If Xorg is crashing , try disabling PAT. Pass the argument {{ic|nopat}} to [[kernel parameters]].<br />
More information about troubleshooting the driver can be found in the [https://forums.geforce.com/ NVIDIA forums.]<br />
<br />
== Bad performance after installing a new driver version ==<br />
<br />
If FPS have dropped in comparison with older drivers, check if direct rendering is enabled ({{ic|glxinfo}} is included in {{Pkg|mesa-demos}}):<br />
$ glxinfo | grep direct<br />
<br />
If the command prints:<br />
direct rendering: No<br />
<br />
A possible solution could be to regress to the previously installed driver version and rebooting afterwards.<br />
<br />
== Avoid screen tearing ==<br />
{{Note|This has been reported to reduce the performance of some OpenGL applications and may produce issues in WebGL.}}<br />
<br />
Tearing can be avoided by forcing a full composition pipeline, regardless of the compositor you are using. To test whether this option will work, run:<br />
$ nvidia-settings --assign CurrentMetaMode="nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }"<br />
<br />
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''.<br />
<br />
In order to make the change permanent, it must be added to the {{ic|"Screen"}} section of the [[Xorg]] configuration file. When making this change, {{ic|TripleBuffering}} should be enabled and {{ic|AllowIndirectGLXProtocol}} should be disabled in the driver configuration as well. See example configuration below:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-nvidia.conf|<nowiki><br />
Section "Device"<br />
Identifier "Nvidia Card"<br />
Driver "nvidia"<br />
VendorName "NVIDIA Corporation"<br />
BoardName "GeForce GTX 1050 Ti"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen0"<br />
Device "Device0"<br />
Monitor "Monitor0"<br />
Option "metamodes" "nvidia-auto-select +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"<br />
Option "AllowIndirectGLXProtocol" "off"<br />
Option "TripleBuffer" "on"<br />
EndSection<br />
</nowiki>}}<br />
<br />
If you do not have an Xorg configuration file, you can create one for your present hardware using {{ic|nvidia-xconfig}} (see [[NVIDIA#Automatic configuration]]) and move it from {{ic|/etc/X11/xorg.conf}} to the preferred location {{ic|/etc/X11/xorg.conf.d/20-nvidia.conf}}.<br />
<br />
{{Note|Many of the configuration options produced in {{ic|20-nvidia.conf}} by using {{ic|nvidia-xconfig}} are set automatically by the driver and are not needed. To only use this file for enabling composition pipeline, only the section {{ic|"Screen"}} containing lines with values for {{ic|Identifier}} and {{ic|Option}} are necessary. Other sections may be removed from this file.}}<br />
<br />
=== Multi-monitor ===<br />
<br />
For multi-monitor setup you will need to specify {{ic|1=ForceCompositionPipeline=On}} for each display. For example:<br />
<br />
$ nvidia-settings --assign CurrentMetaMode="DP-2: nvidia-auto-select +0+0 {ForceCompositionPipeline=On}, DP-4: nvidia-auto-select +3840+0 {ForceCompositionPipeline=On}"<br />
<br />
Without doing this, the {{ic|nvidia-settings}} command will disable your secondary display.<br />
<br />
The above line is for two 3840x2160 monitors connected to DP-2 and DP-4. You will need to read the correct {{ic|CurrentMetaMode}} by exporting {{ic|xorg.conf}} and append {{ic|ForceCompositionPipeline}} to each of your displays. Setting {{ic|ForceCompositionPipeline}} only affects the targeted display. <br />
<br />
{{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 {{ic|~/.nvidia-settings-rc}} as {{ic|<nowiki>0/XVideoSyncToDisplayID=</nowiki>}} or by installing {{pkg|nvidia-settings}} and using the graphical configuration options.}}<br />
<br />
=== Avoid screen tearing in KDE (KWin) ===<br />
At the moment there are two workarounds to try. Do '''not''' apply both workarounds because this may lead to high CPU load [https://bugs.kde.org/show_bug.cgi?id=322060].<br />
<br />
==== 1. GL threads ====<br />
Set GL threads to sleep by exporting {{ic|1=__GL_YIELD="USLEEP"}} to {{ic|kwin_x11}}.<br />
<br />
To apply the workaround on boot:<br />
{{hc|/etc/profile.d/kwin.sh|<nowiki><br />
export __GL_YIELD="USLEEP"<br />
</nowiki>}}<br />
<br />
An another approach is not to export this as global variable, but only export to ''KWin'' on [[Autostart|startup]]:<br />
<br />
{{hc|~/.config/autostart/kwin.sh|<nowiki><br />
(sleep 2s && export __GL_YIELD="USLEEP" && kwin_x11 --replace)<br />
</nowiki>}}<br />
<br />
Mark the script as [[executable]].<br />
<br />
The {{ic|sleep}} argument helps to prevent issues when KWin is restarted/hanging after logging in, you might need to adjust this time.<br />
<br />
==== 2. Use TripleBuffering ====<br />
<br />
Make sure {{ic|TripleBuffering}} has been enabled for the driver, see [[#Avoid screen tearing]].<br />
<br />
Create the {{ic|/etc/profile.d/kwin.sh}} file:<br />
<br />
{{hc|/etc/profile.d/kwin.sh|2=<br />
export KWIN_TRIPLE_BUFFER=1<br />
}}<br />
<br />
Use '''OpenGL 2.0 or later''' as rendering backend under ''Systemsettings'', ''Display and Monitor'', ''Compositor''.<br />
<br />
== Modprobe Error: "Could not insert 'nvidia': No such device" on linux >=4.8 ==<br />
<br />
With linux 4.8, one can get the following errors when trying to use the discrete card:<br />
{{hc|$ modprobe nvidia -vv|<nowiki><br />
modprobe: INFO: custom logging function 0x409c10 registered<br />
modprobe: INFO: Failed to insert module '/lib/modules/4.8.6-1-ARCH/extramodules/nvidia.ko.gz': No such device<br />
modprobe: ERROR: could not insert 'nvidia': No such device<br />
modprobe: INFO: context 0x24481e0 released<br />
insmod /lib/modules/4.8.6-1-ARCH/extramodules/nvidia.ko.gz <br />
</nowiki>}}<br />
{{hc|$ dmesg|<nowiki><br />
...<br />
NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:139b)<br />
NVRM: installed in this system is not supported by the 370.28<br />
NVRM: NVIDIA Linux driver release. Please see 'Appendix<br />
NVRM: A - Supported NVIDIA GPU Products' in this release's<br />
NVRM: README, available on the Linux driver download page<br />
NVRM: at www.nvidia.com.<br />
...<br />
</nowiki>}}<br />
<br />
This problem is caused by bad commits pertaining to PCIe power management in the Linux Kernel (as documented in [https://devtalk.nvidia.com/default/topic/971733/-370-28-with-kernel-4-8-on-gt-2015-machines-driver-claims-card-not-supported-if-nvidia-is-not-primary-card/ this NVIDIA DevTalk thread]). <br />
<br />
The workaround is to add {{ic|1=pcie_port_pm=off}} to your [[kernel parameters]]. Note that this disables PCIe power management for all devices.<br />
<br />
== Poor performance after resuming from suspend ==<br />
<br />
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 [[Kernel modules#Setting module options|loading]] the {{ic|nvidia}} module with the {{ic|1=NVreg_RegisterForACPIEvents=1 NVreg_EnableMSI=1}} options.<br />
<br />
== CPU spikes with 400 series cards ==<br />
<br />
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 {{ic|Device}} section of your Xorg configuration:<br />
<br />
Option "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x3322; PowerMizerDefaultAC=0x1"<br />
<br />
== Full system freeze or crashes when using Flash ==<br />
<br />
If you experience occasional full system freezes using [[Flash]], a possible workaround is to disable Hardware Acceleration:<br />
<br />
{{hc|/etc/adobe/mms.cfg|2=<br />
EnableLinuxHWVideoDecode=0<br />
}}<br />
<br />
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:<br />
export VDPAU_NVIDIA_NO_OVERLAY=1<br />
<br />
== Laptops: X hangs on login/out, worked around with Ctrl+Alt+Backspace ==<br />
<br />
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 {{ic|Ctrl+Alt+Backspace}} (or whatever the new "kill X" key binding is), try adding this in {{ic|/etc/modprobe.d/modprobe.conf}}:<br />
options nvidia NVreg_Mobile=1<br />
<br />
One user had luck with this instead, but it makes performance drop significantly for others:<br />
options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=33 NVreg_DeviceFileMode=0660 NVreg_SoftEDIDs=0 NVreg_Mobile=1<br />
<br />
Note that {{ic|NVreg_Mobile}} needs to be changed according to the laptop:<br />
* 1 for Dell laptops.<br />
* 2 for non-Compal Toshiba laptops.<br />
* 3 for other laptops.<br />
* 4 for Compal Toshiba laptops.<br />
* 5 for Gateway laptops.<br />
<br />
See [ftp://download.nvidia.com/XFree86/Linux-x86/355.11/README/README.txt NVIDIA Driver's README: Appendix K] for more information.<br />
<br />
== Screen(s) found, but none have a usable configuration ==<br />
<br />
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.<br />
<br />
Another thing to try is adding invalid {{ic|"ConnectedMonitor" Option}} to {{ic|Section "Device"}}<br />
to force Xorg throws error and shows you how correct it.<br />
[ftp://download.nvidia.com/XFree86/Linux-x86/355.11/README/xconfigoptions.html Here]<br />
more about ConnectedMonitor setting.<br />
<br />
After re-run X see Xorg.0.log to get valid CRT-x,DFP-x,TV-x values.<br />
<br />
{{ic|nvidia-xconfig --query-gpu-info}} could be helpful.<br />
<br />
== Blackscreen at X startup / Machine poweroff at X shutdown ==<br />
<br />
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:<br />
<br />
* Use the {{ic|<nowiki>rcutree.rcu_idle_gp_delay=1</nowiki>}} [[kernel parameter]].<br />
<br />
* You can also try to add the {{ic|nvidia}} module directly to your [[mkinitcpio]] config file.<br />
<br />
* If the screen still stays black with '''both''' the {{ic|<nowiki>rcutree.rcu_idle_gp_delay=1</nowiki>}} [[kernel parameter]] and the {{ic|nvidia}} module directly in the [[mkinitcpio]] config file, try re-installing {{Pkg|nvidia}} and {{Pkg|nvidia-utils}} in that order, and finally reload the driver:<br />
<br />
# modprobe nvidia<br />
<br />
== Backlight is not turning off in some occasions ==<br />
<br />
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 {{ic|vbetool}} as root.<br />
<br />
Install the {{Pkg|vbetool}} package.<br />
<br />
Turn off your screen on demand and then by pressing a random key backlight turns on again:<br />
<br />
vbetool dpms off && read -n1; vbetool dpms on<br />
<br />
Alternatively, xrandr is able to disable and re-enable monitor outputs without requiring root.<br />
<br />
xrandr --output DP-1 --off; read -n1; xrandr --output DP-1 --auto<br />
<br />
== Xorg fails to load or Red Screen of Death ==<br />
<br />
If you get a red screen and use GRUB, disable the GRUB framebuffer by editing {{ic|/etc/default/grub}} and uncomment {{ic|1=GRUB_TERMINAL_OUTPUT=console}}. For more information see [[GRUB/Tips and tricks#Disable framebuffer]].<br />
<br />
== Black screen on systems with Intel integrated GPU ==<br />
<br />
If you have an Intel CPU with an integrated GPU (e.g. Intel HD 4000) and have installed the {{Pkg|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 {{ic|/etc/modprobe.d/blacklist.conf}} and prevent the ''i915'' and ''intel_agp'' modules from loading on boot:<br />
<br />
{{hc|/etc/modprobe.d/blacklist.conf|<br />
install i915 /usr/bin/false<br />
install intel_agp /usr/bin/false<br />
}}<br />
<br />
== Black screen on systems with VIA integrated GPU ==<br />
<br />
As above, blacklisting the ''viafb'' module may resolve conflicts with NVIDIA drivers:<br />
<br />
{{hc|/etc/modprobe.d/blacklist.conf|<br />
install viafb /usr/bin/false<br />
}}<br />
<br />
== X fails with "no screens found" with Intel iGPU ==<br />
<br />
Like above, if you have an Intel CPU with an integrated GPU and X fails to start with <br />
<br />
[ 76.633] (EE) No devices detected.<br />
[ 76.633] Fatal server error:<br />
[ 76.633] no screens found<br />
<br />
then you need to add your discrete card's BusID to your X configuration. Find it:<br />
<br />
{{hc|<nowiki># lspci | grep VGA</nowiki>|<br />
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)<br />
01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1)<br />
}}<br />
<br />
then you fix it by adding it to the card's Device section in your X configuration. In my case:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/10-nvidia.conf|<br />
Section "Device"<br />
Identifier "Device0"<br />
Driver "nvidia"<br />
VendorName "NVIDIA Corporation"<br />
BusID "PCI:1:0:0"<br />
EndSection<br />
}}<br />
<br />
Note how {{ic|01:00.0}} is written as {{ic|1:0:0}}.<br />
<br />
== Xorg fails during boot, but otherwise starts fine ==<br />
<br />
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.<br />
{{hc|/var/log/Xorg.0.log|output=<br />
[ 1.807] (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module. Please see the<br />
[ 1.807] (EE) NVIDIA(0): system's kernel log for additional error messages and<br />
[ 1.808] (EE) NVIDIA(0): consult the NVIDIA README for details.<br />
[ 1.808] (EE) NVIDIA(0): *** Aborting ***<br />
}}<br />
In this case you will need to establish an ordering dependency from the display manager to the DRI device. First create device units for DRI devices by creating a new udev rules file.<br />
{{hc|/etc/udev/rules.d/99-systemd-dri-devices.rules|output=<br />
ACTION=="add", KERNEL=="card*", SUBSYSTEM=="drm", TAG+="systemd"<br />
}}<br />
Then create dependencies from the display manager to the device(s).<br />
{{hc|/etc/systemd/system/display-manager.service.d/10-wait-for-dri-devices.conf|output=<br />
[Unit]<br />
Wants=dev-dri-card0.device<br />
After=dev-dri-card0.device<br />
}}<br />
If you have additional cards needed for the desktop then list them in Wants and After seperated by spaces.<br />
<br />
== xrandr BadMatch ==<br />
<br />
If you are trying to configure a WQHD monitor such as DELL U2515H using [[xrandr]] and {{ic|xrandr --addmode}} gives you the error {{ic|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 {{ic|1=nouveau.hdmimhz=297}} (or {{ic|330}}) in your [[Kernel parameters]].<br />
<br />
Alternatively, it may be that your monitor's EDID is incorrect. See [[#Override EDID]].<br />
<br />
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).<br />
<br />
If this happens, you may want to add an option to {{ic|/etc/X11/xorg.conf.d/}} to allow non-EDID modes:<br />
<br />
{{bc|<br />
Section "Device"<br />
Identifier "Device0"<br />
Driver "nvidia"<br />
VendorName "NVIDIA Corporation"<br />
...<br />
Option "ModeValidation" "AllowNonEdidModes"<br />
...<br />
EndSection<br />
}}<br />
<br />
This can be set per-output. See NVidia driver readme (Appendix B. X Config Options) for more information.<br />
<br />
== Override EDID ==<br />
<br />
See [[Kernel mode setting#Forcing modes and EDID]] and [[Xrandr#Troubleshooting]].<br />
<br />
== Overclocking with nvidia-settings GUI not working ==<br />
<br />
{{Style|Duplication, vague "not working"}}<br />
<br />
Workaround is to use nvidia-settings CLI to query and set certain variables after enabling overclocking (as explained in [[NVIDIA/Tips and tricks#Enabling overclocking]], see {{man|1|nvidia-settings}} for more information).<br />
<br />
Example to query all variables:<br />
<br />
nvidia-settings -q all<br />
<br />
Example to set PowerMizerMode to prefer performance mode:<br />
<br />
nvidia-settings -a [gpu:0]/GPUPowerMizerMode=1<br />
<br />
Example to set fan speed to fixed 21%:<br />
<br />
nvidia-settings -a [gpu:0]/GPUFanControlState=1 -a [fan:0]/GPUTargetFanSpeed=21<br />
<br />
Example to set multiple variables at once (overclock GPU by 50MHz, overclock video memory by 50MHz, increase GPU voltage by 100mV):<br />
<br />
nvidia-settings -a GPUGraphicsClockOffsetAllPerformanceLevels=50 -a GPUMemoryTransferRateOffsetGPUGraphicsClockOffsetAllPerformanceLevels=50 -a GPUOverVoltageOffset=100</div>Asamarin