NVIDIA (Português)/Troubleshooting (Português)
Falha ao iniciar
Sistema não inicializa após o driver ser instalado
Se após instalar o driver NVIDIA seu sistema fica preso antes de chegar ao gerenciador de display, tente desativar o kernel mode setting.
Xorg falha ao carregar ou Tela Vermelha de Morte
Caso você use o GRUB e se depare com uma tela vermelha, desative o framebuffer do GRUB editando /etc/default/grub e descomentando GRUB_TERMINAL_OUTPUT=console. Para mais informações veja GRUB/Tips and tricks#Disable framebuffer.
Tela preta na inicialização do X / Dispositivo desligando ao finalizar o X
Se você instalou uma atualização da NVIDIA e a sua tela continua preta após lançar o Xorg, ou se o shutdown do Xorg faz com que sua máquina desligue, tente as alternativas abaixo:
- Ponha
xrandr --autono início do seu xinitrc - Use o parâmetro de kernel
rcutree.gp_init_delay=1. - Você também pode tentar adicionar o módulo
nvidiadiretamente ao seu mkinitcpio.conf.
Tela(s) encontrada(s), mas nenhuma tem uma configuração utilizável
Às vezes o driver NVIDIA e o X têm problemas em achar a tela ativa. Caso sua placa gráfica possua múltiplas saídas, tente conectar seu monitor em outras. Em um laptop, o problema pode ser porque sua placa gráfica está mandando VGA/TV para fora. Xorg.0.log lhe dará mais informações.
Outra coisa para se tentar é adicionar uma Option "ConnectedMonitor" inválida em Section "Device" para forçar o Xorg a lançar um erro e te mostrar como corrigí-lo. Veja a documentação para mais informações sobre a configuração ConnectedMonitor.
Depois de re-executar o X, veja Xorg.0.log para conseguir valores CRT-x,DFP-x,TV-x válidos.
nvidia-xconfig --query-gpu-info pode ser de ajuda.
X falha com "Failing initialization of X screen"
Se /var/log/Xorg.0.log diz que o servidor X falhou ao inicializar a tela:
(EE) NVIDIA(G0): GPU screens are not yet supported by the NVIDIA driver (EE) NVIDIA(G0): Failing initialization of X screen
e nvidia-smi diz No running processes found, então a solução consiste em primeiro atualizar nvidia-utils à versão mais recente, e então copiar o arquivo 10-nvidia-drm-outputclass.conf (localizado em /usr/share/X11/xorg.conf.d/) ao diretório /etc/X11/xorg.conf.d/. Depois, adicione a linha Option "PrimaryGPU" "yes" ao arquivo copiado. Finalmente, reinicie o computador. O problema deve agora ter sido resolvido.
Xorg falha durante o boot, mas de outras formas inicia normalmente
Em sistemas com um boot muito rápido, systemd pode tentar iniciar o gerenciador de display antes que o driver NVIDIA esteja completamente inicializado. Você verá uma mensagem parecida com a seguinte em seus logs somente quando o Xorg roda durante o boot:
/var/log/Xorg.0.log
[ 1.807] (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module. Please see the [ 1.807] (EE) NVIDIA(0): system's kernel log for additional error messages and [ 1.808] (EE) NVIDIA(0): consult the NVIDIA README for details. [ 1.808] (EE) NVIDIA(0): *** Aborting ***
Neste caso, você precisará estabelecer uma dependência de ordenação do gerenciador de display ao dispositivo DRI. Primeiro crie unidades de dispositivo para dispositivos DRI criando um novo arquivo de regras udev:
/etc/udev/rules.d/99-systemd-dri-devices.rules
ACTION=="add", KERNEL=="card*", SUBSYSTEM=="drm", TAG+="systemd"
Em seguida, crie dependências do gerenciador de display ao(s) dispositivo(s):
/etc/systemd/system/display-manager.service.d/10-wait-for-dri-devices.conf
[Unit] Wants=dev-dri-card0.device After=dev-dri-card0.device
Caso você tenha placas adicionais necessárias para o desktop, liste-as em Wants e After separadas por espaços.
Tela preta em sistemas com GPU integrada
Se você tem um sistema com uma GPU integrada (e.g. Intel HD 4000, VIA VX820 Chrome 9 ou AMD Cezanne) e instalou o pacote nvidia-580xx-dkmsAUR ou mais antigo, você pode se deparar com uma tela preta na inicialização, ao mudar de terminal virtual, ou ao sair de uma sessão do X. Isto pode ser causado por um conflito entre os módulos gráficos, e é resolvido pondo os módulos GPU relevantes na lista negra. Crie o arquivo /etc/modprobe.d/blacklist.conf e previna os módulos relevantes de serem carregados durante o boot:
/etc/modprobe.d/blacklist.conf
install i915 /usr/bin/false install intel_agp /usr/bin/false install viafb /usr/bin/false install radeon /usr/bin/false install amdgpu /usr/bin/false
X falha com "no screens found" ao usar múltiplas GPUs
Em situações onde você tenha múltiplas GPUs em um sistema e o X não consegue iniciar com:
[ 76.633] (EE) No devices detected. [ 76.633] Fatal server error: [ 76.633] no screens found
então você precisa adicionar o BusID da sua placa dedicada à sua configuração do X. Isto pode acontecer em sistemas com uma CPU Intel e uma GPU integrada ou caso você tenha mais de uma placa NVIDIA conectada. Encontre seu BusID:
# lspci -d ::03xx
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1) 08:00.0 3D controller: NVIDIA Corporation GM108GLM [Quadro K620M / Quadro M500M] (rev a2)
Então, você corrige o erro adicionando-o à seção Device da sua placa na configuração do X. O exemplo a seguir ilustra como a seção deve se parecer (troque os valores por sua própria configuração):
/etc/X11/xorg.conf.d/10-nvidia.conf
Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BusID "PCI:1:0:0"
EndSection
No exemplo acima 01:00.0 é cortado para ser escrito como 1:0:0. Porém, algumas conversões podem ser mais complicadas. A saída do lspci é em formato hexadecimal, mas em arquivos de configuração os BusIDs são em formato decimal! Isto significa que em casos que o BusID é maior que 9 você precisará convertê-lo para decimal! For exemplo: 5e:00.0 vindo do lspci se torna PCI:94:0:0.
Erro do Modprobe: "Could not insert 'nvidia': No such device" no linux >= 4.8
A partir do linux 4.8, você pode receber os seguintes erros ao tentar usar a placa gráfica dedicada:
# modprobe nvidia -vv
modprobe: INFO: custom logging function 0x409c10 registered modprobe: INFO: Failed to insert module '/lib/modules/4.8.6-1-ARCH/extramodules/nvidia.ko.gz': No such device modprobe: ERROR: could not insert 'nvidia': No such device modprobe: INFO: context 0x24481e0 released insmod /lib/modules/4.8.6-1-ARCH/extramodules/nvidia.ko.gz
# dmesg
... 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. ...
Este problema é causado por commits ruins relacionados ao gerenciamento de energia de PCIe no kernel Linux (como documentado nesta thread no NVIDIA DevTalk).
A solução alternativa é adicionar pcie_port_pm=off aos seus parâmetros de kernel. Note que isso desativa o gerenciamento de energia de PCIe para todos os dispositivos.
Sistema não retorna da suspensão
O que você vê no log:
kernel: nvidia-modeset: ERROR: GPU:0: Failed detecting connected display devices kernel: nvidia-modeset: ERROR: GPU:0: Failed detecting connected display devices kernel: nvidia-modeset: WARNING: GPU:0: Failure processing EDID for display device DELL U2412M (DP-0). kernel: nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device DELL U2412M (DP-0) kernel: nvidia-modeset: ERROR: GPU:0: Failure reading maximum pixel clock value for display device DELL U2412M (DP-0).
Uma possível solução baseada em [1]:
Execute este comando para conseguir a string version:
# strings /sys/firmware/acpi/tables/DSDT | grep -i 'windows ' | sort | tail -1
Adicione o parâmetro de kernel acpi_osi=! "acpi_osi=version" à sua configuração do gerenciador de boot.
Outra possível causa do problema pode ser o uso do pacote nvidia-open, conforme descrito aqui:
- https://bbs.archlinux.org/viewtopic.php?pid=2047692
- https://github.com/NVIDIA/open-gpu-kernel-modules/issues/450
- https://github.com/NVIDIA/open-gpu-kernel-modules/issues/223
- https://github.com/NVIDIA/open-gpu-kernel-modules/issues/94
Tela preta ao retornar da suspensão
Caso esteja experienciando problemas de tela preta e os logs contenham:
archlinux kernel: NVRM: GPU at PCI:0000:08:00: GPU-926ecdb0-adb1-6ee9-2fad-52e7214c5011 archlinux kernel: NVRM: Xid (PCI:0000:08:00): 13, pid='<unknown>', name=<unknown>, Graphi> archlinux kernel: NVRM: Xid (PCI:0000:08:00): 13, pid='<unknown>', name=<unknown>, Graphi> archlinux kernel: NVRM: Xid (PCI:0000:08:00): 13, pid='<unknown>', name=<unknown>, Graphi> archlinux kernel: NVRM: Xid (PCI:0000:08:00): 13, pid='<unknown>', name=<unknown>, Graphi> archlinux kernel: NVRM: Xid (PCI:0000:08:00): 13, pid='<unknown>', name=<unknown>, Graphi>
Você precisa ativar os serviços NVIDIA suspend, hibernate, e sleep conforme explicado em NVIDIA/Tips and tricks#Preserve video memory after suspend.
Um ou mais monitores não funcionando em setup multi-monitor no Xorg
Se um ou mais dos seus monitores não está exibindo nada no Xorg e aparece como "Disabled" no painel de control nvidia-settings, então sua configuração do Xorg atual pode estar incompatível. O driver proprietário da NVIDIA não deve requerer uma configuração do X para simplesmente funcionar. Veja NVIDIA (Português)#Configuração do Xorg.
Basta mover ou renomear o arquivo /etc/X11/xorg.conf e quaisquer outros arquivos de configuração em xorg.conf.d relacionados ao driver NVIDIA. Somente arquivos terminados em .conf serão lidos pelo Xorg.
$ mv /etc/X11/xorg.conf /etc/X11/xorg.conf.old
Após desativar a antiga configuração NVIDIA do Xorg, é recomendável usar o nvidia-xconfig para gerar uma nova configuração Xorg para a NVIDIA particularizada ao seu hardware. Isto não deve ser, no entanto, necessário para o funcionamento básico do driver.
$ nvidia-xconfig
nvidia-xconfig de fato cria um arquivo de backup como /etc/X11/xorg.conf.backup, mas ele pode ser sobrescrito ao executar nvidia-xconfig múltiplas vezes.Travamentos e crashes
Crashes em geral
- Tente desativar o firmware GSP.
- Tente desativar
RenderAccelem xorg.conf. - Se o Xorg dá como saída um erro sobre
"conflicting memory type"ou"failed to allocate primary buffer: out of memory", ou dá crash com um "Signal 11" ao usar os drivers nvidia-96xx, adicionenopataos seus parâmetros de kernel. - Se o compilador NVIDIA reclama quanto a diferentes versões do GCC entre a atual e a utilizada para compilar o kernel, adicione, em
/etc/profile:
export IGNORE_CC_MISMATCH=1
- Se aplicativos em tela cheia estão congelando ou crashando, tente ativar as opções
Display CompositingeDirect fullscreen renderingnas configurações do seu ambiente de desktop.
Mau suporte a shaders de malha
Este bug é relevante apenas para novos jogos que dependam deles, como o Final Fantasy VII Rebirth. Isso se reflete na ausência de ambientes ao usar GPUs da NVIDIA mesmo nos drivers beta mais recentes. [2]
Entretanto, o pyroveil lhe permite desviar do problema com o SPIR-V, enquanto espera por uma correção por parte da NVIDIA.
Você precisa compilar e instalar a ferramenta seguindo o tutorial no GitHub, e então rodar o jogo com as variáveis de ambiente PYROVEIL=1 e PYROVEIL_CONFIG=/path/to/pyroveil/hacks/ffvii-rebirth-nvidia/pyroveil.json.
Glitches visuais, travamentos, e erros em aplicativos OpenGL
Se você está usando um CPU recente (Intel Sandy Bridge (2011) e mais recentes ou AMD Zen (2017) e mais recentes), ele tem um cache de micro operações. Usar um cache de micro operações pode levar a problemas com o driver NVIDIA no OpenGL por conta do Cache Aliasing [3]. Em geral você tem como desativar o cache de micro operações no BIOS do seu sistema, mas isto tem um certo custo de performance [4]. Desativar o cache de micro operações também ajuda a resolver os glitches gráficos mais severos em aplicativos Xwayland, embora isto não resolva o problema completamente [5].
Pânico do kernel ao atualizar e/ou reiniciar o sistema
Isto é um bug conhecido que está presente nos drivers NVIDIA da série 550. [6] A causa está por enquanto desconhecida, porém, ele parece afetar somente laptops. Veja BBS#293400 para mais detalhes.
Para desviar do problema, troque para o nvidia-open-dkms caso tenha suporte pelo hardware, caso contrário use o pacote nvidia-535xx-dkmsAUR.
Firmware GSP
O uso de firmware GSP, ativado por padrão desde a versão 555 do driver NVIDIA lançado em junho de 2024, é notório por causar uma gama de problemas, inclusive falhas do Vulkan e crashes do sistema.
Para desativá-lo, use o parâmetro de módulo NVreg_EnableGpuFirmware=0 para o módulo de kernel nvidia. Isso funciona apenas com o driver proprietário da NVIDIA: veja NVIDIA#Instalação caso esteja transicionando do driver de código aberto.
Não esqueça de recriar a initramfs se necessário. Para que esta nova opção de módulo de kernel tenha efeito, reinicie o sistema.
Crashes relacionados à VRR e mudança de TTY
Se o driver dá crash ao trocar de ambientes de desktop e TTYs e o journal diz:
archlinux kernel: [drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID [...]] Flip event timeout archlinux kernel: nvidia-modeset: ERROR: GPU:0: Idling display engine timed out: [...]
Tente desativar a função de taxa de atualização variável (VRR) do seu monitor via o OSD (On-Screen Display) dele.
Outra alternativa é esconder a capacidade do driver de VRR (G-Sync, FreeSync) do subsistema de exibição, prevenindo qualquer aplicativo ou compositor de ativar o VRR: ponha o parâmetro de kernel nvidia_modeset.conceal_vrr_caps=1, que força uma taxa de atualização fixa.
Xid 79, GPU has fallen off the bus
Caso você encontre este crash no journal, ele pode ser causado por diferentes motivos, incluindo uma fonte ruim, cabos, ou problemas de conexão PCI.
Entretanto, ele também foi reportado como um problema do driver NVIDIA, que menciona uma alternativa de limitar o clock da memória.
Primeiro, consiga os clocks da memória disponíveis executando:
$ nvidia-smi -q -d SUPPORTED_CLOCKS | grep Memory
Memory : 9501 MHz
Memory : 9251 MHz
Memory : 5001 MHz
Memory : 810 MHz
Memory : 405 MHz
Em seguida, selecione o maior clock que esteja abaixo do valor máximo, neste caso:
# nvidia-smi -lmc 405,9251
A seleção do valor máximo também funciona, mas aumenta o consumo energético mesmo quando a placa não está sendo usada.
Problemas visuais
Evitar o screen tearing no Xorg
- Já foi reportado que esta solução reduz a performance de alguns aplicativos OpenGL e pode introduzir problems no WebGL. Ela também aumenta drasticamente o tempo necessário para o driver diminuir o ritmo da GPU após uma carga pesada (NVIDIA Support Thread).
ForceFullCompositionPipelineé uma opção notória por quebrar alguns jogos que usam o Vulkan sob o Proton com o driver NVIDIA 535.ForceCompositionPipelineé também notória por fazer com que alguns aplicativos em tela cheia congelem imediatamente, fazendo com que o sistema fique irresponsivo até trocar de janela (e.g. comAlt+Tab). Uma alternativa é executar o programa sob o Gamescope como uma janela sem bordas (-b) e deixar pelo menos alguma outra coisa na tela (que pode ser a barra de tarefas ou qualquer aplicativo gráfico).
O driver NVIDIA aplica condicionalmente um pipeline de composição para preparar a imagem à exibição. Isto não deve ser confundido com um gerenciador de composição, que passa a comandar a apresentação de janelas (e também pode inibir o screen tearing, por meio do V-Sync). Por padrão, o pipeline de composição é aplicado somente no caso das transformações da tela o requisitarem. O pipeline usa a engine especializada de exibição se possível, ou então a engine de gráficos mais geral. Há algumas opções para controlar isso:
ForceCompositionPipelineforça o uso do pipeline (discutido em mais detalhes em #Multi-monitor).ForceFullCompositionPipelineforça o uso do pipeline, e força que tudo seja feito com a engine gráfica.
O screen tearing no Xorg pode ser evitado pondo ForceFullCompositionPipeline=On. Para testar o funcionamento dessa opção, execute:
$ nvidia-settings --assign CurrentMetaMode="nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }"
Ou clique no botão Advanced que está disponível na opção de menu X Server Display Configuration. Selecione ou Force Composition Pipeline ou Force Full Composition Pipeline, e clique em Apply.
Para fazer com que as mudanças sejam permanentes, elas devem ser adicionadas à seção "Screen" do arquivo de configuração do Xorg. Ao fazer esta mudança, a opção TripleBuffering deve ser ativada e AllowIndirectGLXProtocol deve também ser desativada na configuração do driver. Veja um exemplo de configuração abaixo:
/etc/X11/xorg.conf.d/20-nvidia.conf
Section "Device"
Identifier "NVIDIA Card"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "GeForce GTX 1050 Ti"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
Option "ForceFullCompositionPipeline" "on"
Option "AllowIndirectGLXProtocol" "off"
Option "TripleBuffer" "on"
EndSection
Caso você não tenha um arquivo de configuração do Xorg, você pode criar um para o seu hardware atual usando o nvidia-xconfig (veja NVIDIA (Português)#Configuração automática) e mova-o de /etc/X11/xorg.conf para a localização preferencial /etc/X11/xorg.conf.d/20-nvidia.conf.
20-nvidia.conf ao usar o nvidia-xconfig são postas automaticamente pelo driver e não são necessárias. Para usar este arquivo somente para ativar o pipeline de composição, apenas a seção "Screen" contendo linhas com valores para Identifier e Option é necessária. Outras seções podem ser removidas deste arquivo.Multi-monitor
Para um setup multi-monitor, você precisará especificar ForceCompositionPipeline=On para cada display. Por exemplo:
$ nvidia-settings --assign CurrentMetaMode="DP-2: nvidia-auto-select +0+0 {ForceCompositionPipeline=On}, DP-4: nvidia-auto-select +3840+0 {ForceCompositionPipeline=On}"
Sem fazer isso, o comando nvidia-settings vai desativar seu display secundário.
A linha acima serve para dois monitores 3840x2160 conectados a DP-2 e DP-4. Você precisará ler o CurrentMetaMode correto exportando xorg.conf e adicionando ForceCompositionPipeline para cada um dos seus displays. A opção ForceCompositionPipeline afeta somente o display alvo na configuração.
Você pode obter os nomes atuais das telas e seus respectivos offsets usando a opção --query:
$ nvidia-settings --query CurrentMetaMode
~/.nvidia-settings-rc pela opção 0/XVideoSyncToDisplayID= ou instalando o nvidia-settings e usando as opções de configuração da interface gráfica.Corrompimento da tela ao retornar da suspensão ou hibernação
Isto também se aplica caso um monitor externo não se ative após a suspensão ou hibernação.
Veja NVIDIA (Português)/Tips and tricks (Português)#Preserve video memory after suspend.
Um bug de corrompimento após a suspensão ao usar o serviço GDM foi resolvido desde a versão 515.43.04 do driver [7].
Tela corrompida: Problema das "seis telas"
Para alguns usuários, usando a GeForce GT 100M, a tela fica corrompida após a inicialização do X, dividida em 6 seções com resolução limitada a 640x480. O mesmo problema já foi reportado com a Quadro 2000 e displays de alta-resolução.
Para resolver este problema, ative o Validation Mode NoTotalSizeCheck na seção Device:
Section "Device" ... Option "ModeValidation" "NoTotalSizeCheck" ... EndSection
Textos e ícones invisíveis com o driver nvidia-470
Uma atualização do GTK4 trouxe um problema aos usuários que dependem do driver nvidia-470 para placas de legado. Após a atualização, textos e ícones desaparecem aleatoriamente e reaparecem apenas ao passar o mouse por cima das janelas.[8]
Veja o fórum para maneiras de despistar esse problema.
Corrigir o corrompimento gráfico do GNOME Shell ao retornar do modo de descanso
Caso você esteja vendo fontes estranhas e/ou tendo glitches gráficos no GNOME Shell ao retornar do modo de descanso (sleep), tente colocar o seguinte parâmetro de kernel para ativar o gerenciamento de energia:
nvidia.NVreg_DynamicPowerManagement=0x02
Mais informações em: https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/dynamicpowermanagement.html
System freeze when the display powers off or on resume
If the system freezes or crashes right after the desktop environment turns off the display (DPMS) or when resuming from suspend, and dmesg/journal shows a GSP timeout like:
NVRM: _kgspLogXid119: ********************************* GSP Timeout ********************************** NVRM: Xid (PCI:0000:01:00): 119, Timeout after 6s of waiting for RPC response from GPU0 GSP! Expected function 76 (GSP_RM_CONTROL) sequence 1321
the GPU may be dropping to an unstable low clock state during these power transitions.
Workaround: lock a higher minimum GPU/memory clock with nvidia-smi.
Prerequisites:
Enable/start the nvidia-persistenced.service.
Find supported clock values (use these to pick valid min/max pairs):
nvidia-smi -q -d SUPPORTED_CLOCKS nvidia-smi -q -d CLOCK
Temporary test
Set minimum clocks (example values; adjust to your GPU’s max supported clocks):
nvidia-smi -lgc 800,2100 nvidia-smi -lmc 800,10000 Test DPMS and suspend/resume to see if the issue is resolved. To revert: nvidia-smi -rgc nvidia-smi -rmc
Permanent configuration (systemd)
Create a unit such as nvidia-clocks.service:
/etc/systemd/system/nvidia-clocks.service
[Unit] Description=Set NVIDIA GPU minimum clocks to avoid GSP timeouts Requires=nvidia-persistenced.service After=nvidia-persistenced.service [Service] Type=oneshot ExecStart=/usr/bin/nvidia-smi -lgc 500,2100 ExecStart=/usr/bin/nvidia-smi -lmc 500,10000 RemainAfterExit=yes [Install] WantedBy=multi-user.target
You can adjust the minimum clock so they are lower than the 800 mentioned earlier to lower idle power consumption; just be aware that setting them to low will cause the issue to occur again.
Then enable/start nvidia-clocks.service.
Performance issues
Bad performance after installing a new driver version
If FPS have dropped in comparison with older drivers, check if direct rendering is enabled (glxinfo is included in mesa-utils):
$ glxinfo | grep direct
If the command prints:
direct rendering: No
A possible solution could be to regress to the previously installed driver version and rebooting afterwards.
Extreme lag on Xorg
A common issue with Mutter is that animations, video playback and gaming cause extreme desktop lag on Xorg.
See NVIDIA/Tips and tricks#Preserve video memory after suspend.
This should resolve this issue, however if it did not, you are most likely out of luck. One way you can remedy this issue is by adding these options:
/etc/environment
CLUTTER_DEFAULT_FPS=YOUR_MAIN_DISPLAY_REFRESHRATE __GL_SYNC_DISPLAY_DEVICE=YOUR_MAIN_DISPLAY_OUTPUT_NAME
turning Sync to VBlank and Allow flipping off within NVIDIA Settings, and configuring NVIDIA Settings to launch on startup using the flag --load-config-only.
This will still result in a laggy desktop behavior, in particular on an eventual second (or third) monitor, but it should be much better.
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:
Option "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x3322; PowerMizerDefaultAC=0x1"
Other issues
Vulkan error on applications start
On executing an application that require Vulkan acceleration, if you get this error
Vulkan call failed: -4
try to delete the ~/.nv or ~/.cache/nvidia directory.
No audio over HDMI
Sometimes NVIDIA HDMI audio devices are not shown when you do
$ aplay -l
On some new machines, the audio chip on the NVIDIA GPU is disabled at boot. Read more on NVIDIA's website and a forum post.
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 is going to reset:
# setpci -s 01:00.0 0x488.l=0x2000000:0x2000000 # rmmod nvidia-drm nvidia-modeset nvidia # echo 1 > /sys/bus/pci/devices/0000:01:00.0/remove # echo 1 > /sys/bus/pci/devices/0000:00:01.0/rescan # modprobe nvidia-drm # xinit -- -retro
If you are running your TTY on NVIDIA, put the lines in a script so you do not end up with no screen.
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.
Install the vbetool package.
Turn off your screen on demand and then by pressing a random key backlight turns on again:
vbetool dpms off && read -n1; vbetool dpms on
Alternatively, xrandr is able to disable and re-enable monitor outputs without requiring root.
xrandr --output DP-1 --off; read -n1; xrandr --output DP-1 --auto
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 enabled by default since 440.26. If you are using an older driver, the HardDPMS option can be set in the Device or Screen sections. For example:
/etc/X11/xorg.conf.d/20-nvidia.conf
Section "Device"
...
Option "HardDPMS" "true"
...
EndSection
Section "Screen"
...
Option "HardDPMS" "true"
...
EndSection
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
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 by 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 is just that current NVIDIA drivers are too restrictive).
If this happens, you may want to add an option to xorg.conf to allow non-EDID modes:
Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
...
Option "ModeValidation" "AllowNonEdidModes"
...
EndSection
This can be set per-output. See README - Appendix B. X Config Options for more information.
Override EDID
See Kernel mode setting#Forcing modes and EDID, Xrandr#Troubleshooting and Qnix QX2710#Fixing X11 with Nvidia.
Overclocking with nvidia-settings GUI not working
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 in nvidia-settings, see nvidia-settings(1) for more information).
Example to query all variables:
nvidia-settings -q all
Example to set PowerMizerMode to prefer performance mode:
nvidia-settings -a [gpu:0]/GPUPowerMizerMode=1
Example to set fan speed to fixed 21%:
nvidia-settings -a [gpu:0]/GPUFanControlState=1 -a [fan:0]/GPUTargetFanSpeed=21
Example to set multiple variables at once (overclock GPU by 50MHz, overclock video memory by 50MHz, increase GPU voltage by 100mV):
nvidia-settings -a GPUGraphicsClockOffsetAllPerformanceLevels=50 -a GPUMemoryTransferRateOffsetAllPerformanceLevels=50 -a GPUOverVoltageOffset=100
Overclocking not working with Unknown Error
If you are running Xorg as a non-root user and trying to overclock your NVIDIA GPU, you will get an error similar to this one:
$ nvidia-settings -a "[gpu:0]/GPUGraphicsClockOffset[3]=10"
ERROR: Error assigning value 10 to attribute 'GPUGraphicsClockOffset' (trinity-zero:1[gpu:0]) as specified in assignment
'[gpu:0]/GPUGraphicsClockOffset[3]=10' (Unknown Error).
To avoid this issue, Xorg has to be run as the root user. See Xorg#Rootless Xorg for details.
Power draw
Check driver usage:
# lsof /dev/nvidia*
kwin_wayl 867 user 17u CHR 195,0 0t0 418 /dev/nvidia kwin_wayl 867 user 18u CHR 195,0 0t0 418 /dev/nvidiactl
If power save is configured on the kernel module:
$ grep . /sys/bus/pci/devices/0000:01:00.0/power/*
/sys/bus/pci/devices/0000:01:00.0/power/control:auto /sys/bus/pci/devices/0000:01:00.0/power/runtime_active_time:445933 /sys/bus/pci/devices/0000:01:00.0/power/runtime_status:active /sys/bus/pci/devices/0000:01:00.0/power/runtime_suspended_time:1266 /sys/bus/pci/devices/0000:01:00.0/power/wakeup:disabled
# rmmod nvidia_drm
$ grep . /sys/bus/pci/devices/0000:01:00.0/power/*
/sys/bus/pci/devices/0000:01:00.0/power/control:auto /sys/bus/pci/devices/0000:01:00.0/power/runtime_active_time:461023 /sys/bus/pci/devices/0000:01:00.0/power/runtime_status:suspended /sys/bus/pci/devices/0000:01:00.0/power/runtime_suspended_time:1064192 /sys/bus/pci/devices/0000:01:00.0/power/wakeup:disabled
Test software GL
The binary NVIDIA driver will not adhere to the Mesa environment variable LIBGL_ALWAYS_SOFTWARE=1 but you can direct libglvnd and EGL to use Mesa by setting the following environment variables:
__GLX_VENDOR_LIBRARY_NAME=mesa __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json
which will result in the Mesa libgl being used for GLX and EGL and result in software GL to see whether a bug is related to the NVIDIA GL library.
Refresh-rate limited to 120Hz
Newer versions of the driver (after 550xx) seem to waste bandwidth on 8bpc outputs, likely pushing the signal above specification limits and the result is a failure to apply modes with higher refresh rates that otherwise would be within the specification of the output.
Add nvidia-modeset.hdmi_deepcolor=0 to the kernel parameters or set the option via modprobe
Notice that deep color will however be required for HDR monitors.
Wrong color space on 60hz on Wayland with HDMI
In some cases (like using a HDMI cable with a 1660 Super Graphics Card with 60hz), the driver seems to wrongly assume the color space for the output. This leads to the colors looking darker than normal. Because of there being no easy way to explicitly set the color space on Wayland, as a workaround you can add nvidia-modeset.debug_force_color_space=2 to the kernel parameters or set the option via modprobe.