Linux 7.3 apresenta falha com monitores em dock Thunderbolt 5; desenvolvedor testa correção Regressão no driver gráfico Intel i915 interrompeu o sinal de dois monitores DisplayPort em um notebook Lenovo; patch experimental recuperou o funcionamento durante testes.
Atualização do Linux 7.3 interrompe sinal de monitores externos
Em 13 de novembro de 2026, o desenvolvedor Frederik Schwan relatou uma regressão no subsistema gráfico do kernel Linux. O problema está diretamente relacionado ao driver Intel i915 e ao treinamento de conexões DisplayPort UHBR. A falha foi documentada utilizando um notebook Lenovo, modelo 21Q8CTO1WW, equipado com processador Intel Meteor Lake (PCI ID 8086:7d51) e conectado a uma ThinkPad Thunderbolt 5 Smart Dock 7500.
O equipamento de teste utilizava três monitores 4K conectados à dock station, sendo dois ligados por portas DisplayPort e um por conexão USB-C. No kernel Linux 7.2, todas as telas operavam normalmente. Após a atualização do sistema para a série Linux 7.3, os monitores DisplayPort passaram a perder o sinal de vídeo no momento exato em que o kernel assumia o controle gráfico durante a inicialização. O monitor conectado pela porta USB-C, no entanto, continuou funcionando sem interrupções.
Desenvolvedor identifica alteração responsável pela regressão
Para isolar a origem do problema, Schwan utilizou a ferramenta git bisect, que permite rastrear e comparar o histórico de alterações de código entre as versões 7.2 e 7.3 do Linux. A investigação apontou com precisão o primeiro commit associado ao comportamento incorreto, identificado sob o código 1fd440de4e02efab97874bbda0a4daf59d228fa3 (drm/i915/dp_tunnel: Add UHBR tunneling support).
Essa alteração foi introduzida originalmente com o objetivo de acrescentar suporte ao transporte de sinais DisplayPort em taxas elevadas UHBR (Ultra High Bit Rate) por meio de conexões Thunderbolt. A implementação desse novo caminho de execução de código acabou expondo uma condição preexistente na lógica responsável por configurar os parâmetros elétricos do transmissor gráfico da Intel.
Por que o driver Intel i915 falhou com Thunderbolt 5
A perda de imagem ocorreu devido a uma falha na aplicação dos parâmetros físicos da conexão de vídeo. Durante o treinamento do link UHBR, os valores de equalização (FFE) solicitados pelo monitor receptor eram devidamente atualizados nas estruturas de negociação em software, mas não eram aplicados ao transmissor físico da GPU.
O problema se manifestou por causa da presença de repetidores LTTPR na conexão Thunderbolt. Uma instrução condicional na função intel_dp_set_signal_levels() impedia a chamada necessária para atualizar os níveis elétricos do sinal de vídeo sempre que esses repetidores estavam no trajeto. Como resultado direto, o treinamento das conexões nas velocidades UHBR20 e UHBR10 falhava de forma contínua. O sistema de vídeo ainda tentava recorrer ao padrão anterior HBR3, mas o processo de habilitação do mecanismo de correção de erros (FEC) sofria esgotamento de tempo (timeout), mantendo as duas telas DisplayPort apagadas.
Patch experimental recupera conexão DisplayPort
Com a origem da falha mapeada, o desenvolvedor elaborou uma correção no arquivo drivers/gpu/drm/i915/display/intel_dp_link_training.c. A modificação garante que a rotina de configuração dos níveis elétricos do transmissor seja sempre executada durante o treinamento UHBR, mesmo quando existem repetidores LTTPR gerenciando o sinal. Para o treinamento tradicional 8b/10b, a condição de execução anterior foi mantida intacta.
Os testes em hardware foram conduzidos utilizando um ambiente Arch Linux executando o kernel modificado 7.3.4-arch1-2. Após a compilação do patch, o treinamento UHBR20 foi concluído com sucesso utilizando quatro vias de transmissão (lanes). Os processos de equalização dos canais e o alinhamento entre as vias também foram finalizados de maneira adequada. Os registros técnicos (logs) do sistema demonstraram duas sequências consecutivas e bem-sucedidas de treinamento.
Cabe ressaltar que os resultados positivos foram obtidos e validados em uma configuração bastante específica. O próprio relatório reconhece que esses testes iniciais não comprovam estabilidade de longo prazo e não atestam completamente a recuperação limpa em todas as situações de alternância técnica entre UHBR e HBR3.
OpenAI Codex auxiliou na investigação do kernel Linux
A apuração do problema contou com o uso de inteligência artificial como ferramenta de apoio à programação. Frederik Schwan relatou ter utilizado o OpenAI Codex para auxiliar na análise dos densos registros do kernel, na interpretação de trechos da documentação técnica e na elaboração da lógica do patch.
A ferramenta não operou de forma autônoma. O desenvolvedor foi o responsável exclusivo por orquestrar o rastreamento via git bisect, compilar as diferentes matrizes do kernel e executar as validações físicas conectando o notebook à dock. A inteligência artificial funcionou estritamente como um suporte para verificações estáticas, demonstrando uma aplicação prática de como ferramentas de linguagem estão sendo inseridas no fluxo de depuração humana de sistemas complexos.
Quais computadores e monitores podem ser afetados?
Até o presente momento, a regressão está comprovadamente documentada apenas na combinação de processadores Intel Meteor Lake operando em conjunto com a ThinkPad Thunderbolt 5 Smart Dock 7500 e telas gerenciadas via saídas DisplayPort nativas. O comportamento anômalo atinge especificamente instalações atualizadas para o Linux 7.3. A abrangência real dessa falha em outras arquiteturas Intel ou diferentes docks Thunderbolt ainda não foi estabelecida pela comunidade.
Como verificar a versão do kernel e identificar o driver gráfico
Usuários de Linux que enfrentam telas pretas ao utilizar docks modernas podem verificar os componentes base do sistema utilizando três comandos de terminal seguros (focados apenas em leitura de dados):
uname -rexibe a versão exata do kernel Linux que está gerenciando a máquina no momento.lspci -nnklista os barramentos e dispositivos de hardware conectados, indicando qual driver gráfico está atrelado à placa de vídeo (como o módulo i915).journalctl -k -b | grep -Ei 'i915|drm|thunderbolt|UHBR|link training'realiza uma filtragem nos registros da sessão atual, buscando erros específicos de negociação do sinal de vídeo.
Encontrar falhas de treinamento de link no registro não confirma automaticamente a ocorrência da mesma regressão. Cabos danificados e limitações no controlador do próprio monitor também geram notificações semelhantes no sistema.
Quando a correção poderá chegar ao Linux?
O patch submetido permanece em estado experimental. O código e os relatórios de teste foram enviados para as listas oficiais de discussão do subsistema gráfico (intel-gfx e dri-devel), onde aguardam o parecer dos mantenedores do projeto DRM da Intel. A correção precisará passar por revisão por pares, validação cruzada em hardwares diferentes e checagens automatizadas antes de ser mesclada na árvore drm-fixes e distribuída nas futuras atualizações estáveis do kernel.
Entenda sem termos técnicos: por que uma atualização pode apagar a imagem de um monitor
Quando você conecta um computador a um monitor moderno através de uma dock station, a imagem não aparece por mágica instantânea. Os aparelhos precisam conversar primeiro para definir a velocidade e a qualidade da transmissão. Essa negociação inicial é chamada de “treinamento”.
Durante essa etapa, o monitor pede ao computador que ajuste a força do sinal elétrico para que a imagem seja nítida. Na atualização 7.3 do Linux, um erro sutil na programação fez com que o computador registrasse o pedido do monitor, mas deixasse de aplicar essa mudança de força no conector físico. Como o sinal de vídeo saía muito fraco ou desajustado, os aparelhos encerravam a negociação com erro e as telas ficavam completamente pretas. A correção experimental serve justamente para garantir que o computador entregue a força elétrica exata que o monitor exigiu.
