Monitor secundário (Nvidia) não inicia no Boot? Resolvendo o "Race Condition" no Ubuntu (25.10)

Linux Dicas e Tutoriais
, , , ,
1

Problemas de exibição e falhas na GPU em sistemas dual-boot são complexos e podem ter várias origens: desde cabos HDMI de má qualidade, configurações de BIOS/Secure Boot, até conflitos de ACPI.

Aqui focaremos em uma das causas mais comuns: a falha de sincronização (race condition) entre o Kernel e o Driver Nvidia durante a transição do estado de energia do hardware no “reboot quente”. Se o seu monitor só liga no Ubuntu após você “visitar” o Windows 11, este guia é para você.

:face_with_monocle: A Causa Técnica

O Windows 11 inicializa a GPU de forma agressiva. Ao reiniciar diretamente para o Ubuntu, a placa pode ficar “presa” em um estado de energia que o driver Linux não consegue resetar a tempo. O resultado é um monitor HDMI que permanece em standby.

A Solução: Ativando o Early Modesetting

A correção consiste em forçar o carregamento do driver nvidia-drm no estágio inicial do boot, garantindo que ele “reivindique” a placa antes que a interface gráfica tente acessá-la.

1. Modificação do Parâmetro do Kernel

Edite o arquivo de configuração do GRUB:

Bash

sudo nano /etc/default/grub

Localize a variável GRUB_CMDLINE_LINUX_DEFAULT. Adicione o parâmetro de modosetting:

Plaintext

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvidia-drm.modeset=1"

Salve com Ctrl+O, Enter e saia com Ctrl+X.

2. Persistência e Atualização do Sistema

Para que o Kernel reconheça a mudança, você deve reconstruir a imagem de inicialização (initramfs) e atualizar o menu do GRUB. Execute o comando combinado:

Bash

sudo update-grub && sudo update-initramfs -u

3. Validação

Reinicie o sistema. Para confirmar que o sistema aplicou a regra, execute:

Bash

cat /proc/cmdline

O output deve conter obrigatoriamente nvidia-drm.modeset=1.

:light_bulb: Dicas e Troubleshooting Avançado

  • A “Armadilha” do Fast Startup: O Windows 11 não desliga totalmente por padrão (Hibernação do Kernel). Se o Windows não “liberar” os registros da GPU, o Linux não conseguirá inicializá-la. Desative a Inicialização Rápida nas opções de energia do Windows.

  • Cold Boot (O Reset Físico): Se após uma atualização o monitor não ligar, desligue o PC, remova o cabo de energia por 10 segundos e ligue novamente. Isso drena a energia dos capacitores da GPU, limpando estados de erro persistentes.

  • Logs em tempo real: Se o problema persistir, o erro exato estará nos logs do kernel. Verifique com:

    dmesg | grep -i nvidia

  • Wayland vs X11: O Ubuntu 25.10 usa Wayland por padrão. Se o comportamento for errático, teste a sessão X11 na tela de login para isolar se o problema é o protocolo de exibição ou o driver.

:red_exclamation_mark: Lembre-se: Esta é uma solução específica para falhas de inicialização de driver. Se o problema for físico ou de firmware (BIOS desatualizada), os passos acima podem não ser suficientes.

:green_circle: UPDATE: A Solução Definitiva

Se após aplicar o nvidia-drm.modeset=1 o seu monitor ainda falha intermitentemente, o problema pode ser um conflito de barramento PCIe causado pelo modo Intel RST (RAID) na BIOS.

O Sintoma “Invisível”

Nos logs do sistema (dmesg), observamos que o SSD e a GPU Nvidia disputavam o mesmo endereço de barramento (01:00.0), fazendo com que o driver Nvidia entrasse em um loop infinito de inicialização.

A Correção de Hardware (Modo AHCI)

O Linux tem dificuldade em mapear dispositivos quando a BIOS está em modo RAID, pois a Intel “esconde” os endereços reais dos componentes.

A Solução Real:

  1. Prepare o Windows: Como o Windows não inicia após mudar para AHCI sem preparação, no Windows, abra o CMD (Admin) e digite: bcdedit /set {current} safeboot minimal.

  2. Acesse a BIOS (F2): Na aba Main, pressione Ctrl + S para liberar opções ocultas (no Acer Nitro é assim).

  3. Altere o SATA Mode: Mude de “Optane with RAID …” para AHCI.

  4. Finalize no Windows: Inicie em Modo de Segurança, abra o CMD (Admin) e digite: bcdedit /deletevalue {current} safeboot.

O Resultado Esperado

Após essa mudança, ao rodar lspci -nn | grep -E "0300|0108" no Ubuntu, você verá que cada dispositivo ganhou seu próprio endereço exclusivo:

  • GPU Nvidia: Fixada em 01:00.0.

  • SSDs NVMe: Movidos para barramentos distintos (ex: 06:00.0 e 07:00.0).

  • Os endereços de barramento (ex: 01:00.0) mudam. Vale observar se o endereço de um SSD está “pulando” para o lugar (endereço) da Nvidia. O importante é você observar que os endereços estão distintos como (ex: 01:00.0 para a GPU e 06:00.0/07:00.0 para os discos).

Isso encerra a “guerra de barramento” e permite que o nvidia-smi funcione instantaneamente em cada boot, sem depender de “visitas” ao Windows para resetar a placa.

:light_bulb: Dicas

  • Atenção ao Reset: Se você atualizar a BIOS do seu laptop, ela pode voltar para o modo RAID automaticamente. Se o Ubuntu parar de carregar, cheque o modo SATA primeiro.

  • Limpeza: Com o modo AHCI ativo, parâmetros como pci=realloc ou pci=nocrs tornam-se desnecessários e devem ser removidos do seu GRUB para evitar erros de montagem de disco.

  • 0300 e 0108: Estes são códigos de classe universais do padrão PCI para Controladores de Vídeo e Controladores de Memória NVMe, respectivamente. Eles funcionam em qualquer distribuição Linux para identificar esses tipos específicos de hardware.

  • Persistence Mode: Para manter a placa sempre “acordada” no Ubuntu, você pode ativar o modo de persistência com sudo nvidia-smi -pm 1.

1 curtida