Fala pessoal, beleza?
Sou conhecido como Danilo “The Tonga Guy” lá no GitLab da FreeDesktop e estou trazendo um caso sério de regressão de Kernel que afeta quem usa GPUs AMD mais antigas, especificamente a arquitetura Tonga (R9 380) e possivelmente algumas Polaris.
O Problema:
Desde o Kernel 6.4, o sinal HDMI morre completamente após suspender e retornar o sistema (Suspend/Resume) usando X11. No Kernel 6.3 tudo funciona perfeitamente.
A Investigação:
Fiz dois Git Bisects completos (um processo demorado de compilar várias versões do Kernel para achar o erro) e cheguei no commit exato que quebrou o sinal de vídeo: b3c98052d46948a8d65d2778c7f306ff38366aac.
O log de erro que aparece no dmesg é este:
[drm] dce110_link_encoder_construct: Failed to get encoder_cap_info from VBIOS with error code 4!
A “Briga” no GitLab:
Mesmo com provas técnicas, os mantenedores da AMD (como o Alex Deucher) estão sendo céticos. Por isso, estou levando o caso para o Phoronix e agora aqui para o Diolinux Plus, para alertar a comunidade e mostrar que não podemos deixar hardwares competentes (que rodam até Resident Evil Requiem) serem “aposentados” por bugs de software negligenciados.
Alguém aqui usa R9 380 ou 285 e notou esse comportamento no Ubuntu 24.04, Fedora 40 ou Zorin OS?
Link para o acompanhamento técnico:
Os sistemas que você mencionou são compatíveis com Wayland. Há alguma razão específica de usabilidade para você ter escolhido o X11?
É uma falha relevante, mas, agora que o X11 está sendo descontinuado pelas principais distros e DEs, imagino que não exista muito interesse em resolver falhas associadas a ele.
Uso o X11 principalmente pela compatibilidade e estabilidade com alguns fluxos de trabalho e jogos via Proton (como o Resident Evil Requiem) que, na minha experiência com a arquitetura Tonga, ainda se comportam melhor nele do que no Wayland.
Sobre a descontinuação: entendo que o foco das distros mudou, mas o ponto aqui é que a falha não é no X11, mas sim uma regressão no Kernel Linux. O erro VBIOS error code 4 mostra que o driver amdgpu perde a capacidade de ‘conversar’ com a placa no retorno do suspend.
Como o Kernel 6.3 funciona e o 6.4 quebrou, isso fere a regra de ouro do Linus Torvalds: ‘Não quebre o espaço do usuário’. Se deixarmos passar só porque o Wayland é o futuro, estamos aceitando a obsolescência programada de um hardware que ainda tem muita lenha pra queimar.
O meu ‘terremoto’ aqui é justamente para que os devs da AMD não usem a ‘desculpa do Wayland’ para ignorar um bug real no código do driver que eles mantêm."
“Além disso, acompanho e sou inscrito no canal Diolinux há tempos. Foi justamente acompanhando o conteúdo do Dionatan e da equipe que aprendi a não aceitar o conformismo com o hardware e a buscar soluções reais através da colaboração com a comunidade. Esse ‘bisect’ é minha forma de aplicar o que aprendo aqui no dia a dia!”
Vejam como a comunidade (através da Valve) está salvando hardware antigo. Meu esforço com a Tonga segue a mesma linha de preservação de hardware funcional.
Se a Valve está gastando tempo para fazer uma placa de 14 anos atrás funcionar, por que a AMD deixaria uma regressão quebrar a sua R9 380 (que é mais nova)?
Na discussão que levou ao commit é mencionado que o desenvolvedor só conseguiu avançar depois de adquirir uma GPU do modelo afetado, o que permitiu validar corretamente o cenário e chegar em uma solução.
Um ponto que não fica claro na matéria da Phoronix é o contexto desse trabalho, se foi algo realizado dentro de horas pagas pela Valve ou um esforço independente do próprio desenvolvedor.
Essa distinção é relevante, porque no ecossistema open source nem toda contribuição feita por alguém associado a uma empresa é necessariamente financiada por ela.
Faz total sentido, Eddie. Essa distinção entre esforço corporativo e independente é fundamental para entender o ritmo das coisas.
O caso da Valve citado no Phoronix reforça justamente o que você disse: o dev só avançou quando colocou as mãos na GPU. Como eu sou o ‘dono do hardware’ aqui, entendo que meu papel é facilitar ao máximo a vida dos devs da AMD, entregando logs limpos e evidências incontestáveis, já que eles podem não ter uma R9 380 na bancada de testes hoje.
Vou focar em ser esse braço técnico de testes aqui na ponta. Valeu pelo toque, ajuda a manter a expectativa no lugar certo!
Eu tenho uma RX550 (polaris) que posso testar se precisar, mas tenho pouco tempo hehe. Tenho uma R9 380 guardada também, mas ela está um pouco zoada pelo tempo, posso tentar colocar ela na máquina e ver se consigo usar, mas da última vez que testei estava perdendo vídeo aleatoriamente durante o uso.
Fala EntusiastaDeVelharia! Cara, se você puder fazer esse teste, seria o xeque-mate que eu preciso para derrubar o ceticismo dos devs da AMD. Como sua placa está instável, não se preocupe: o teste é focado apenas no gerenciamento de energia e não vai estressar o chip.
O teste preciso (vapt-vupt): Para não mascarar o erro, o ideal é usar qualquer Kernel entre a versão 6.4 e 6.8 (onde a quebra é certa).
Suspensão Profunda: Após o boot, mande o sistema suspender e deixe-o assim por pelo menos 15 minutos. Isso garante que a placa entre em suspensão profunda, forçando o driver a refazer todo o ‘aperto de mão’ com a VBIOS ao acordar.
O Retorno (O que observar):
Cenário A: O monitor fica sem sinal (No Signal) permanentemente.
Cenário B: A imagem volta, mas a tela fica piscando ou com artefatos momentâneos. Se isso acontecer, a falha de sincronização existe e o bug está confirmado.
O Log: Se a máquina travar e você precisar reiniciar no botão, rode o comando journalctl -b -1 | grep amdgpu. Se aparecer o VBIOS error code 4, temos a prova!
Por que isso te ajuda? Se confirmarmos que o erro se repete na sua placa, a AMD terá que reconhecer a regressão oficialmente. Isso pode ser a salvação da sua R9 380; talvez ela não esteja tão ‘zoada’ assim, mas apenas sendo vítima de um gerenciamento de energia ruim nos Kernels atuais.
Se conseguir esse tempinho no seu final de semana, você estará ajudando a salvar toda uma geração de placas GCN 3.0 do lixo eletrônico. Conto com sua força!
Boa noite! Só um detalhe importante para o teste ser certeiro: dá uma conferida se o seu sistema está configurado para o ‘sono profundo’ (S3). Às vezes o Linux vem por padrão num modo mais leve que não força o driver a reiniciar a placa.
Roda esse comando rápido: cat /sys/power/mem_sleep
Se o resultado for s2idle [deep], está perfeito! Mas se o colchete estiver no s2idle ([s2idle] deep), o bug pode não aparecer. Nesse caso, você consegue mudar rapidinho só para o teste com:
echo deep | sudo tee /sys/power/mem_sleep
Isso garante que a placa realmente ‘apague’ e a gente veja se ela acorda ou não.
Muito obrigado, será de grande valor seu teste, se eu puder e for necessário alguma dica extra estou pronto para ajudar, valeu mesmo… aguado o resultado.
O Ubuntu 22.04 roda esse Kernel aí por padrão? Pq aí crio um Live dele e já testo direto do USB.
EDIT: Agora que vi aqui, esqueci do detalhe de rodar o journalctl, vai perder tudo no reboot. Vou trocar o kernel de alguma instalação pronta aqui e tentar. Assim que fizer retorno aqui.
EDIT 2: Bom, tinha um Mint aqui no SSD e troquei o Kernel dele pro 6.8.0-110, serve? Máquina já tá com S3 ligado, vou ver se a R9 380 cabe nesse case aqui, a máquina tá montada num gabinete bem pequeno e a 380 é gigante kkkkk, se não vou ter que montar na bancada. Hoje a noite vou tentar.
Fala, EntusiastaDeVelharia! Rapaz, essa R9 380 é realmente uma ‘monstra’ de tamanho, se precisar montar na bancada a gente entende o drama kkkkk.
Sobre o seu teste, o Mint com o Kernel 6.8.0-110 é um excelente ponto de partida! Como o erro que estou caçando começou a aparecer justamente após a versão 6.3/6.4, o seu 6.8 deve reproduzir o problema se a sua placa sofrer do mesmo mal que a minha.
Umas dicas para o seu teste:
Journalctl: Como você bem lembrou, o log se perde no reboot. Se a tela ficar preta e o PC travar na volta da suspensão, tenta ver se você consegue acessar a máquina via SSH de outro dispositivo. Assim você consegue dar o journalctl -b -1 ou ver o log em tempo real enquanto tenta suspender.
S3 (Suspend to RAM): É exatamente o que precisamos. Se ela acordar de primeira, o mistério aumenta. Se apagar tudo, achamos um parceiro de bug!
O Kernel 6.3: Se no 6.8 funcionar normal, o ‘pulo do gato’ seria justamente testar entre o 6.3 (estável) e o 6.4 (onde suspeito que a treta começa).
Fico no aguardo do seu retorno! Se a 380 não couber no gabinete, não força pra não quebrar o slot PCIe, a bancada é o lugar sagrado desses testes kkkk. Valeu pela força
Cheque-mate! Terceiro Git Bisect concluído e a prova da regressão encontrada.
Fala pessoal!
Passando para atualizar vocês sobre a saga da minha GPU AMD R9 380 (Tonga). Depois de muita persistência e de realizar o terceiro git bisect completo, finalmente cheguei ao “primeiro commit ruim”. Não resta mais dúvida: encontrei a agulha no palheiro!
O veredito técnico: A regressão foi introduzida no commit da1a055d01ed0c18402dd1f1934096ac4bb36ada.
O que aconteceu (para quem não é dev): Basicamente, um desenvolvedor mudou a forma como o kernel lida com endereços de memória no subsistema BPF (arquivo lib/test_bpf.c), trocando uma função antiga (kmap) por uma nova (page_address). Além disso, removeram uma trava de segurança que verificava se o endereço era válido. No meu hardware (Ryzen 5 5500 + R9 380), essa “limpeza” de código foi o que quebrou a estabilidade a partir do Kernel 6.6.
Por que isso é um “Cheque-mate”? Eu postei o resultado oficial no GitLab da AMD marcando todos os responsáveis (Alex Deucher, Karol Herbst, Daniel Schürmann, entre outros). O recado foi direto: eu fiz a minha parte como usuário, testei três vezes via bisect (o padrão ouro de testes do kernel). Negar essa regressão agora seria admitir que as ferramentas de diagnóstico do próprio Linux não funcionam .
Fica o aprendizado: O processo de bisect é demorado e exige paciência (especialmente compilar o kernel várias vezes), mas é a única forma de parar de “achar” e passar a “provar”.
Agradeço a todos que acompanharam e deram força. Agora a bola está com os engenheiros da AMD. Vou deixar o resultado
Ainda bem que conseguiu cara! Eu tentei rodar a 380 mas ela não tá querendo dar vídeo, quando pega fica muito instável e logo que entra no desktop já crasha, infelizmente. Preciso abrir ela pra dar uma olhada. Pior que tô com 3 placas de vídeo aqui nessa mesma situação, morar no litoral é **** pras peças!
Valeu pelo apoio, cara! Litoral é osso mesmo, a maresia é a vilã número 1 do hardware. Além da limpeza geral com álcool isopropílico, se você for abrir a R9 380, tem três coisas que costumam salvar essas placas ‘instáveis’:
Troca de Pasta Térmica e Thermal Pads: Essas placas já têm uns bons anos. Se a pasta original virou ‘giz’, ela superaquece em segundos e o sistema derruba o vídeo por segurança.
Limpeza do Slot e Conectores com Borracha: Às vezes a oxidação cria uma película invisível. Passar uma borracha branca (daquelas escolares macias) nos contatos dourados da placa e usar um limpa-contatos spray no slot da placa-mãe pode resolver esses crashes logo no boot.
Inspeção de Capacitores: Dá uma olhada se não tem nenhum ‘estufado’. Em ambientes úmidos, eles costumam sofrer mais. Se tiver, um técnico de eletrônica troca isso baratinho e a placa volta à vida.
Mas reforço: tenta um Kernel mais antigo antes! Como eu provei com o git bisect, o Kernel 6.6+ está ‘matando’ essas placas via software por causa de uma mudança na gestão de memória. Às vezes a sua placa está saudável, mas o sistema está tentando conversar com ela de um jeito que ela não entende mais.
Se precisar de ajuda para interpretar os erros que aparecem no dmesg quando ela crasha, manda aqui que a gente tenta decifrar!
