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, escolha para o clock mínimo a menor frequência permitida, e para o clock máximo uma abaixo do valor mais alto, especificado como um par min,max, usando a opção --lock-memory-clocks (ou -lmc), e.g.:
# nvidia-smi --lock-memory-clocks 405,9251
Isto define um intervalo de frequências de clock permitidas, o que para de forçar o dispositivo a sempre usar a mais alta. Colocar o máximo do intervalo na frequência máxima também funciona, mas aumenta o consumo energético mesmo quando a placa não está sob uso.
--lock-memory-clocks não funciona em dispositivos baseados em arquiteturas NVIDIA Hopper. Se este é o seu caso, ao invés disso use a opção --lock-memory-clocks-deferred (ou -lmcd), que pede como input um único valor de frequência desejado, ao invés de um intervalo.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]
Uma alternativa é selecionar o renderizador:
/etc/environment
GSK_RENDERER=vulkan
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
Sistema congela quando o display desliga ou ou retornar da suspensão
Se o sistema congela ou dá crash logo após o ambiente de desktop desligar o display (DPMS) ou ao retornar o sistema da suspensão, e o dmesg/journal mostra um timeout GSP do tipo:
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
a GPU pode estar caindo para um estado de clock baixo instável durante estas transições de energia.
Solução alternativa: fixar um clock de memória/GPU maior com o nvidia-smi.
Pré-requisitos:
Ative/inicie o serviço nvidia-persistenced.service.
Encontre os valores de clock permitidos (use-os para escolher pares min/max válidos):
nvidia-smi -q -d SUPPORTED_CLOCKS nvidia-smi -q -d CLOCK
Ponha clocks mínimos (valores apenas de exemplo; ajuste-os às maiores frequências suportadas pela sua GPU):
nvidia-smi -lgc 800,2100 nvidia-smi -lmc 800,10000
Teste o DPMS e a suspensão/retorno para ver se o problema foi resolvido. Para reverter:
nvidia-smi -rgc nvidia-smi -rmc
Para uma configuração permanente (systemd), crie uma unidade como 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
Você pode ajustar o clock mínimo de tal forma que ele seja menor que o 800 mencionado antes, para diminuir o consumo energético quando em standby; tenha em mente, no entanto, que diminuí-lo fará o problema aparecer novamente.
Finalmente, ative/inicie nvidia-clocks.service.
Problemas de performance
Picos de CPU com placas da série 400
Caso você esteja vendo picos de CPU intermitentes com uma placa da série 400, isto pode ser devido ao PowerMizer constantemente mudar a frequência de clock da GPU. Mudando a configuração do PowerMizer do Adaptive para o Performance, adicione a seguinte opção para a seção Device da sua configuração do Xorg:
Option "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x3322; PowerMizerDefaultAC=0x1"
Outros problemas
Sem áudio através de HDMI
Às vezes dispositivos de áudio HDMI da NVIDIA não aparecem ao fazer:
$ aplay -l
Em algumas máquinas novas, o chip de áudio na GPU NVIDIA é desativado na inicialização. Leia mais sobre no website da NVIDIA e em um post do fórum.
Você precisa recarregar o dispositivo NVIDIA com o áudio ativado. Para fazer isso, certifique-se de que sua GPU está ligada (no caso de laptops/Bumblebee) e que você não está rodando o X nela, pois ele será resetado:
# 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
Se você está rodando seu TTY na NVIDIA, ponha as linhas acima em um script para que você não acabe ficando sem uma tela.
Luz de fundo não desliga em algumas ocasiões
Por padrão, DPMS deveria desligar a luz de fundo com os timeouts postos ou ao executar xset. Entretanto, devido a provavelmente um bug nos drivers proprietários da NVIDIA, o resultado é uma tela em branco sem qualquer tipo de economia de energia. Para evitar este problema até que o bug seja corrigido você pode usar o vbetool como usuário raiz.
Instale o pacote vbetool.
Desligue sua tela quando quiser, e então, ao pressionar uma tecla aleatória, a luz de fundo deve ligar novamente:
vbetool dpms off && read -n1; vbetool dpms on
De modo alternativo, o xrandr é capaz de desativar e reativar saídas de monitores sem precisar de privilégios de raiz.
xrandr --output DP-1 --off; read -n1; xrandr --output DP-1 --auto
HardDPMS
O driver proprietário 415 inclui um recurso novo chamado HardDPMS. Segundo alguns usuários, isto resolve os problemas de suspensão de monitores conectados via DisplayPort.
Ele é ativado por padrão desde a versão 440.26. Se você está usando um driver mais antigo, a opção HardDPMS pode ser posta nas seções Device ou Screen. Por exemplo:
/etc/X11/xorg.conf.d/20-nvidia.conf
Section "Device"
...
Option "HardDPMS" "true"
...
EndSection
Section "Screen"
...
Option "HardDPMS" "true"
...
EndSection
HardDPMS será invocado em situações de screensaving, tipo BlankTime. As seguintes ServerFlags farão com que seu(s) monitor(es) entre(m) em suspensão após 10 minutos de inatividade:
/etc/X11/xorg.conf.d/20-nvidia.conf
Section "ServerFlags"
Option "BlankTime" "10"
EndSection
xrandr BadMatch
Se você está tentando configurar um monitor WQHD como o DELL U2515H usando xrandr e xrandr --addmode dá o erro X Error of failed request: BadMatch, pode ser porque o driver proprietário NVIDIA limita a frequência máxima do clock de pixels na saída HDMI para 225MHz ou mais baixa. Para pôr o monitor na resolução máxima você terá de instalar os drivers nouveau. Você pode forçar o nouveau a usar uma frequência de clock de pixels pondo nouveau.hdmimhz=297 (ou 330) em seus parâmetros do kernel.
De forma alternativa, pode ser que o EDID do seu monitor está incorreto. Veja #Sobrepor o EDID.
Outro motivo pode ser que por padrão os drivers NVIDIA atuais permitirão somente os modos explicitamente reportados pelo EDID, mas às vezes taxas de atualização e/ou resoluções são desejadas que não são reportadas pelo monitor (embora a informação do EDID esteja correta; é só que os drivers NVIDIA atuais são restritivos demais).
Se isso acontecer, pode ser de seu interesse adicionar uma opção ao xorg.conf para permitir modos não-EDID:
Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
...
Option "ModeValidation" "AllowNonEdidModes"
...
EndSection
Isto pode ser posto para cada saída. Veja README - Appendix B. X Config Options para mais informações.
Sobrepor o EDID
Veja Kernel mode setting#Forcing modes and EDID, Xrandr#Solução de problemas e Qnix QX2710#Fixing X11 with Nvidia.
Overclock não funciona com Unknown Error
Se você está rodando o Xorg como um usuário não-raiz e está tentando fazer overclock na sua GPU NVIDIA, você verá um erro similar a este:
$ 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).
Para evitá-lo, o Xorg deve ser executado como usuário raiz. Veja Xorg#Xorg sem root para mais detalhes.
Testar GL por software
O binário do driver NVIDIA não vai seguir a variável de ambiente Mesa LIBGL_ALWAYS_SOFTWARE=1, mas você pode direcionar o libglvnd e EGL para usar o Mesa pondo as seguintes variáveis de ambiente:
__GLX_VENDOR_LIBRARY_NAME=mesa __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json
que resultará no libgl do Mesa sendo usado para GLX e EGL, ou seja, em renderização GL por software, e portanto sendo útil para testar se um determinado bug está relacionado à biblioteca GL da NVIDIA.
Taxa de atualização limitada a 120Hz
Novas versões do driver (após 550xx) parecem desperdiçar bandalarga em saídas 8bpc, provavelmente elevando o sinal acima dos limites da especificação e o resultado é uma falha em aplicar modos com taxas de atualização mais altas que caso contrário estariam dentro da especificação da saída. Adicione nvidia-modeset.hdmi_deepcolor=0 aos parâmetros do kernel ou ponha a opção via modprobe. Tenha em mente que a cor profunda (deep color) será necessária para monitores HDR.
Espaço de cores errado em 60Hz no Wayland com HDMI
Em alguns casos (como usar um cabo HDMI com uma placa gráfica 1660 Super em 60Hz), o driver aparenta assumir erroneamente o espaço de cores da saída. Isso faz com que as cores pareçam mais escuras que o normal. Como não há nenhuma forma simples de escolher o espaço de cores no Wayland, como alternativa você pode adicionar nvidia-modeset.debug_force_color_space=2 aos parâmetros do kernel ou definir a opção via modprobe.