Olá, pessoal!
Estou trazendo uma mobilização importante para quem usa GPUs da arquitetura AMD Tonga (GCN 3.0). Identificamos uma regressão crítica que está quebrando a estabilidade dessas placas a partir do Kernel 6.6, causando crashes ao suspender/retomar o sistema.
O trabalho pesado de “detetive” já foi feito: realizamos 3 ciclos completos de git bisect e isolamos o culpado no commit da1a055d. Já provamos que reverter esse commit manualmente resolve 100% do problema.
Por que precisamos de você?
Embora o diagnóstico técnico esteja pronto, precisamos mostrar para os engenheiros da AMD e desenvolvedores do Kernel que existe uma comunidade ativa usando esse hardware. Não podemos deixar que “limpezas de código” transformem placas perfeitamente funcionais em lixo eletrônico.
Modelos afetados (exemplos):
Sapphire Nitro R9 380 / MSI Gaming R9 380 / ASUS Strix R9 380 / Gigabyte G1 / XFX / PowerColor / R9 285 / R9 M390 e M395 (iMacs).
Como ajudar? (Leva 2 minutos)
Mesmo que você não esteja sofrendo o erro agora, sua interação ajuda a dar prioridade ao conserto oficial. Por favor, acesse os links e manifeste seu apoio (pode ser com um comentário simples ou um “like/me afeta”):
GitLab (Foco Técnico): Certificando de que você não é um bot!
Launchpad (Para quem usa Ubuntu/Zorin/Mint): Clique em “Does this bug affect you?”
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2142389
Compartilhem este post! Vamos mostrar a força da nossa comunidade brasileira de Linux para manter o hardware legado vivo e estável. 
#LinuxKernel #AMDGPU #TongaRegression
Bisseção concluída e entregue – O caminho para o conserto das R9 380
Fala pessoal, trago atualizações importantes sobre a nossa mobilização.
Concluí a terceira bisseção completa do kernel e os dados são irrefutáveis: isolamos o ponto exato onde a estabilidade das AMD Tonga (R9 380) acaba. O erro de memória (Null Pointer Dereference) em amdgpu_bo_get_memory surge exatamente nesse trecho do código.
O que foi feito:
-
Entreguei o relatório técnico completo no GitLab da AMD/Freedesktop.
-
Os logs provam que no “kernel pai” o sistema é 100% estável, com S3 Sleep/Resume (BACO) e jogos funcionando perfeitamente.
-
Identificamos que a remoção de proteções de memória no commit
da1a055dcoincide com o início dos travamentos.
Situação atual: O clima no GitLab ficou um pouco tenso por causa do timing das postagens no fim de semana, mas já reforcei que nossa intenção é puramente construtiva: salvar uma geração de GPUs e garantir que a regra de “nenhuma regressão” do Kernel Linux seja respeitada.
Pedido à comunidade:
Agora precisamos de paciência. O trabalho técnico de “perícia” (bisect) está feito. Vamos aguardar a análise dos desenvolvedores durante a semana. Peço que ninguém vá ao GitLab para cobrar ou “pingar” os devs agora; isso pode atrapalhar o processo. Se você tem o mesmo problema, guarde seus logs, pois eles podem ser úteis em breve.
Estamos mais perto do que nunca de uma solução oficial. Agradeço a força de todos!
Danilo “The Tonga Guy”
Danilo, bom dia!
Isso é realmente necessário? Eu vi que os devs já sinalizaram que estão procurando o ponto exato onde o “bug” ocorre, aguardando o seu log correto.
Pela ultima resposta do Karol, fica subentendido que se seu log estiver errado, eles vão ignorar.
Eu compreendo perfeitamente sua mobilização, e seus esforços para evitar que uma geração de GPU sejam afetadas, mas da mesma forma eu entendo que os devs não tem a obrigação de analisar um log inconsistente e ensinar a debugar.
Outra coisa, como dito pelo Venemo, tente usar seu inglês mesmo que ruim, eu concordo, ler centenas de mensagens feitas por IA é cansativo pra caramba.
Enfim, estarei acompanhando diretamente no Gitlab, e espero que surja realmente uma solução.
Boa sorte!
Boa tarde!! pedrozord! Obrigado pelo toque. Você tem razão, o clima pesou e eu já mudei a postura. Acabei de entregar o log completo do bisect e a validação do commit pai lá no GitLab. Agora vou ficar em silêncio e deixar os devs trabalharem no tempo deles. O trabalho técnico de campo eu já fiz, agora é com eles. Valeu pela força!
Olha, pode ser que não seja a mesma coisa, mas adquiri um rx570 de oportunidade. Para a minha surpresa, ela não está funcionando em sessões wayland. Não sei o que pode ser. Dei uma leve pesquisada, li algo sobre regressão de kernel a partir do 6.8.
https://forums.linuxmint.com/viewtopic.php?t=453297
No x11 o comportamento é normal… em wayland, black screen e monitor vai dormir. Ao acessar o TTY, tudo normal novamente, bem como ao retornar para o X11. Testei Kbuntu 26.04 e Debian 13 com KDE em sessão wayland.
Fala, sr_llucas! Cara, que coincidência você comentar isso.
Sua RX 570 (Polaris) é a “irmã mais nova” da minha arquitetura (Tonga), e o que você descreveu — tela preta no Wayland e o monitor entrando em suspensão — é exatamente o sintoma que estamos investigando nas regressões do Kernel 6.6+.
Muitas vezes, uma mudança no código que afeta o gerenciamento de energia ou o mapeamento de memória no driver amdgpu acaba respingando em várias gerações da AMD (GCN 3, 4 e 5). Esse link do fórum do Mint que você mandou reforça muito a tese de que o Kernel 6.8+ trouxe instabilidades que não existiam antes.
O que eu te recomendaria para testar:
-
Se tiver um tempinho, dá uma olhada no log do seu sistema logo após esse erro (
journalctl -b -1 -p 3). Se aparecer algo sobre “ring gfx timeout” ou “amdgpu: [gfxhub] vmc page fault”, estamos falando da mesma família de bugs. -
Se puder, entra no link do Launchpad que postei ali em cima e marca que o bug também te afeta. Mesmo sendo placas diferentes, o fato de serem regressões de Kernel no mesmo driver ajuda a dar peso para os desenvolvedores olharem o caso com urgência.
Hardware da AMD no Linux costuma ser “vinho”, melhora com o tempo, mas essas regressões recentes estão testando nossa paciência! Valeu por compartilhar seu relato, ajuda muito a mostrar que o problema é mais amplo.
Já encontrei isso daqui:
luciano@luciano-x99b9:~$ sudo journalctl -b -1 -p 3
mai 04 22:03:37 luciano-x99b9 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT1.SPT0._GTF.DSSP], AE_NOT_FOUND (20250404/psargs-332)
mai 04 22:03:37 luciano-x99b9 kernel: ACPI Error: Aborting method \_SB.PCI0.SAT1.SPT0._GTF due to previous error (AE_NOT_FOUND) (20250404/psparse-529)
mai 04 22:03:37 luciano-x99b9 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT1.SPT2._GTF.DSSP], AE_NOT_FOUND (20250404/psargs-332)
mai 04 22:03:37 luciano-x99b9 kernel: ACPI Error: Aborting method \_SB.PCI0.SAT1.SPT2._GTF due to previous error (AE_NOT_FOUND) (20250404/psparse-529)
mai 04 22:03:37 luciano-x99b9 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT1.SPT0._GTF.DSSP], AE_NOT_FOUND (20250404/psargs-332)
mai 04 22:03:37 luciano-x99b9 kernel: ACPI Error: Aborting method \_SB.PCI0.SAT1.SPT0._GTF due to previous error (AE_NOT_FOUND) (20250404/psparse-529)
mai 04 22:03:37 luciano-x99b9 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT1.SPT2._GTF.DSSP], AE_NOT_FOUND (20250404/psargs-332)
mai 04 22:03:37 luciano-x99b9 kernel: ACPI Error: Aborting method \_SB.PCI0.SAT1.SPT2._GTF due to previous error (AE_NOT_FOUND) (20250404/psparse-529)
mai 04 22:03:38 luciano-x99b9 kernel: EDAC sbridge: CPU SrcID #0, Ha #0, Channel #0 has DIMMs, but ECC is disabled
mai 04 22:03:38 luciano-x99b9 kernel: EDAC sbridge: Couldn't find mci handler
mai 04 22:03:38 luciano-x99b9 kernel: EDAC sbridge: Couldn't find mci handler
mai 04 22:03:38 luciano-x99b9 kernel: EDAC sbridge: Failed to register device with error -19.
mai 04 22:04:55 luciano-x99b9 login[2799]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory
mai 04 22:04:55 luciano-x99b9 login[2799]: PAM adding faulty module: pam_lastlog.so
mai 04 22:18:13 luciano-x99b9 login[4796]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory
mai 04 22:18:13 luciano-x99b9 login[4796]: PAM adding faulty module: pam_lastlog.so
e
sudo journalctl -b | grep -i amdgpu
[sudo] senha para luciano:
mai 05 12:07:45 luciano-x99b9 kernel: [drm] amdgpu kernel modesetting enabled.
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu: Virtual CRAT table created for CPU
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu: Topology: Add CPU node
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: initializing kernel modesetting (POLARIS10 0x1002:0x67DF 0x1002:0x0B31 0xEF).
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: register mmio base: 0xFBE00000
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: register mmio size: 262144
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: detected ip block number 0 <vi_common>
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: detected ip block number 1 <gmc_v8_0>
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: detected ip block number 2 <tonga_ih>
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: detected ip block number 3 <gfx_v8_0>
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: detected ip block number 4 <sdma_v3_0>
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: detected ip block number 5 <powerplay>
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: detected ip block number 6 <dm>
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: detected ip block number 7 <uvd_v6_0>
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: detected ip block number 8 <vce_v3_0>
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu 0000:02:00.0: No more image in the PCI ROM
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: Fetched VBIOS from ROM BAR
mai 05 12:07:45 luciano-x99b9 kernel: amdgpu: ATOM BIOS: xxx-xxx-xxx
mai 05 12:07:46 luciano-x99b9 kernel: amdgpu 0000:02:00.0: vgaarb: deactivate vga console
mai 05 12:07:46 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: Trusted Memory Zone (TMZ) feature not supported
mai 05 12:07:46 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: vm size is 256 GB, 2 levels, block size is 10-bit, fragment size is 9-bit
mai 05 12:07:46 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: VRAM: 8192M 0x000000F400000000 - 0x000000F5FFFFFFFF (8192M used)
mai 05 12:07:46 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: GART: 256M 0x000000FF00000000 - 0x000000FF0FFFFFFF
mai 05 12:07:46 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: amdgpu: 8192M of VRAM memory ready
mai 05 12:07:46 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: amdgpu: 32067M of GTT memory ready.
mai 05 12:07:46 luciano-x99b9 kernel: amdgpu: hwmgr_sw_init smu backed is polaris10_smu
mai 05 12:07:46 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: [drm] Display Core v3.2.340 initialized on DCE 11.2
mai 05 12:07:46 luciano-x99b9 kernel: snd_hda_intel 0000:02:00.1: bound 0000:02:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu])
mai 05 12:07:46 luciano-x99b9 kernel: kfd kfd: amdgpu: Allocated 3969056 bytes on gart
mai 05 12:07:46 luciano-x99b9 kernel: kfd kfd: amdgpu: Total number of KFD nodes to be created: 1
mai 05 12:07:46 luciano-x99b9 kernel: amdgpu: Virtual CRAT table created for GPU
mai 05 12:07:46 luciano-x99b9 kernel: amdgpu: Topology: Add dGPU node [0x67df:0x1002]
mai 05 12:07:46 luciano-x99b9 kernel: kfd kfd: amdgpu: added device 1002:67df
mai 05 12:07:46 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: Using BACO for runtime pm
mai 05 12:07:46 luciano-x99b9 kernel: amdgpu 0000:02:00.0: [drm] Registered 6 planes with drm panic
mai 05 12:07:46 luciano-x99b9 kernel: [drm] Initialized amdgpu 3.64.0 for 0000:02:00.0 on minor 1
mai 05 12:07:46 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: [drm] Failed to setup vendor infoframe on connector HDMI-A-1: -22
mai 05 12:07:46 luciano-x99b9 kernel: fbcon: amdgpudrmfb (fb0) is primary device
mai 05 12:07:46 luciano-x99b9 kernel: amdgpu 0000:02:00.0: [drm] fb0: amdgpudrmfb frame buffer device
mai 05 12:07:46 luciano-x99b9 sensors[1293]: amdgpu-pci-0200
mai 05 12:08:40 luciano-x99b9 kernel: amdgpu 0000:02:00.0: amdgpu: Disabling VM faults because of PRT request!
Isso daqui me chamou atenção: [drm] Failed to setup vendor infoframe on connector HDMI-A-1: -22. Embora não tenha sido no horário que testei wayland, talvez o X11 tenha alguma forma de lidar com isso que o wayland não consiga. Mas isso é apenas suposição. Não entendo nada disso rsrsrs…
Boa, sr_llucas! Você acabou de “matar a charada” de onde o driver está engasgando.
Essas linhas de log são fundamentais. Vou destacar dois pontos aqui que mostram como o seu problema e o meu (das Tonga) estão no mesmo barco:
-
Failed to setup vendor infoframe on connector HDMI-A-1: -22: Esse erro-22(Invalid Argument) indica que o Kernel está tentando enviar uma instrução de vídeo que a placa não reconhece ou que foi mal formatada no código novo. Isso explica por que no Wayland (que exige uma comunicação muito mais rígida com o driver) a tela apaga, enquanto no X11 ele ainda consegue “dar um jeitinho”. -
Disabling VM faults because of PRT request!: Isso aqui é o driver “jogando a toalha” na proteção de memória. É um sintoma clássico de instabilidade no gerenciamento de recursos da GPU.
O que isso prova para nós: O Kernel está tentando tratar as placas GCN (como a sua Polaris e a minha Tonga) com parâmetros de placas mais novas, e quando o hardware antigo recebe essa instrução ‘moderna’ demais ou mal ‘limpa’ (como aquele commit que eu mencionei), ele simplesmente corta o sinal de vídeo para se proteger.
Dica de ouro: se você puder, poste esses logs lá no ticket do Launchpad que eu linkei no post principal. Relatos de placas Polaris (RX 400/500) sofrendo com HDMI Infoframe em Kernels 6.8+ ajudam MUITO a provar que não é um caso isolado de uma placa velha, mas sim uma falha de arquitetura no driver atual.
Estamos chegando em algum lugar! Se mais gente com RX 470/480/570/580 estiver lendo isso e passando pelo mesmo no Wayland, saibam que não é defeito na placa de vocês, é software!"
Aconteceu uma coisa bizarra aqui comigo esses dias. Fui ligar a máquina e minha placa mãe começou a apitar erro de GPU com a RX550. A placa parou de dar vídeo, pro meu azar, mas também pra minha sorte quando coloquei a R9 380 ela ficou relativamente mais estável que antes. Porém no Mint ficou muito lenta a performance e travando constantemente, na minha instalação do Windows 10, depois de passar um DDU e instalar um driver limpo, a performance ficou boa e sem engasgos. Estranho, que antigamente era justamente o contrário, no Windows ficava horrível e no Linux ficava ótimo. Vou fazer mais testes e colocar outra distro com um Kernel mais antigo. No 6.8 a performance ficou inviável. Estou com algum mal olhado ou maldição aqui nas placas de vídeo, *****!!! Já tô com 3 VGAs mortas aqui!
Pessoal, as peças do quebra-cabeça estão se encaixando! Ninguém aqui está com “azar” ou “mal olhado”. O que estamos vendo é a prova real de uma regressão de software que está afetando diferentes gerações de hardware AMD.
Uma ótima notícia: Nossa mobilização no Launchpad já subiu de 6 para 8 pessoas confirmando que o bug as afeta! Pode parecer pouco, mas para os desenvolvedores do Kernel, cada novo clique aumenta a prioridade do conserto.
Para o @EntusiastaDeVelharia:
Cara, não é maldição, é regressão técnica pura! O fato da sua R9 380 (Tonga) estar lenta e travando no Linux Mint (Kernel 6.8), enquanto brilha no Windows 10, é o sintoma clássico do que descobrimos.
Antigamente o Linux era o “refúgio” dessas placas porque o driver amdgpu era super otimizado. O que aconteceu nos Kernels recentes foi justamente o contrário: uma “limpeza” de código mal planejada que quebrou o gerenciamento de performance da arquitetura Tonga. Se você testar uma distro com Kernel 6.1 (LTS) ou anterior, vai ver sua R9 380 “voltar à vida”. Não jogue suas VGAs fora, elas só precisam de um software que as respeite!
Para o @sr_llucas:
Luciano, esse print do seu terminal (image_daea59.jpg) é o “batom na cueca”! O momento em que o SDDM (Greeter) tenta iniciar a sessão Wayland e recebe um Process crashed com exit code 1 mostra que o subsistema gráfico falhou ao se comunicar com o kernel.
O Wayland é muito mais exigente. Aquele erro de HDMI Infoframe (-22) que você encontrou causa exatamente esse crash: o Kernel envia uma instrução inválida, o processo quebra e o sistema te joga de volta pro X11 ou pra tela preta.
Chamada Geral: Vamos chegar aos 10?
Luciano, EntusiastaDeVelharia e todos que estão acompanhando: precisamos da força de vocês agora.
Já provamos tecnicamente o erro (com 3 git bisects), agora precisamos provar que há usuários reais sendo prejudicados. Acessem o link abaixo e cliquem em “This bug affects you” (no canto superior esquerdo):
Já subimos para 8 usuários. Se chegarmos aos 10 ou mais, o bug ganha um novo status de visibilidade. Vamos mostrar que hardware funcional não deve ser descartado por erro de código!
#LinuxKernel #AMDGPU #TongaRegression
Boa, @sr_llucas! Não há argumento melhor do que a prática. 
Ver esse seu print do Debian 12 com Wayland funcionando perfeitamente no Kernel 6.1 é a prova real de tudo o que discutimos aqui. Como você disse: não é mágica, é Kernel estável! Isso confirma que entre a versão 6.1 e a 6.8 algo “quebrou” no driver das nossas AMD.
Para quem está acompanhando o tópico e quer continuar em distros mais novas (como o Ubuntu 24.04 ou Mint 22) sem abrir mão da estabilidade, aqui vão duas dicas úteis enquanto o conserto oficial não vem:
-
Kernels LTS ou Mainline: Uma opção é usar ferramentas como o
zxtuneou omainlinepara instalar um Kernel mais antigo (como o 6.1 LTS) mesmo em sistemas novos. -
Fixar o Kernel: Se você encontrou uma versão que funciona, lembre-se de “segurar” a atualização dele (
apt-mark hold) para o sistema não sobrescrever com a versão problemática automaticamente.
Pessoal, o Luciano provou o ponto! O bug é real e afeta quem quer usar tecnologias novas (Wayland). Também X11 no meu caso. Já somos 8 usuários oficiais no Launchpad. Se você também tem uma RX 500 ou R9 e quer poder usar o Kernel mais novo sem esses travamentos, nos ajude a chegar nos 10 cliques!
Cada clique no ‘This bug affects you’ aumenta o ‘Bug Heat’ e faz o sistema do Ubuntu dar prioridade para nós.
Bug #2142389 “amdgpu (R9 380) fails to resume from suspend (deep...” : Bugs : linux package : Ubuntu
Valeu pelo teste, Luciano! Isso deu um peso enorme para o nosso relatório.
VITÓRIA DA COMUNIDADE: O BUG FOI OFICIALMENTE CONFIRMADO!
Pessoal, trago notícias que aquecem o coração de qualquer entusiasta. A união de vocês gerou um resultado concreto agora mesmo! Conforme registrado na Captura de tela de 2026-05-05 17-58-40.png, nosso esforço coletivo surtiu efeito.
O Launchpad Janitor (o sistema de triagem do Ubuntu) acaba de atualizar o relatório: o status mudou oficialmente para “Confirmed” porque o sistema reconheceu que o problema afeta múltiplos usuários. Além disso, nossa chama de “Bug Heat” saltou para 12!
O que isso significa na prática? No desenvolvimento do Kernel, sair de “New” para “Confirmed” é um divisor de águas. O problema deixou de ser um “relato isolado” e foi oficialmente validado pela triagem do Ubuntu como uma falha real que precisa de atenção. Esse é o primeiro grande passo para que o conserto seja priorizado pelos desenvolvedores.
Um agradecimento especial:
-
Ao @sr_llucas, pela disposição em partir para a “força bruta” e provar com o Debian 12 que o hardware está saudável. Seu teste (conforme a image_d8a0fa.png) foi a peça fundamental para isolarmos a regressão.
-
Ao @EntusiastaDeVelharia, por compartilhar o seu caso. Saiba que não há “maldição” nas suas placas; é apenas o código precisando de um ajuste para respeitar o legado dessas GPUs guerreiras.
É apenas o início da nossa vitória… Embora tenhamos vencido essa etapa, o caminho até a solução final depende de mantermos essa mobilização viva. Cada novo clique no botão “This bug affects you” funciona como um lembrete para os mantenedores de que há uma comunidade ativa esperando por isso. Se você ainda não deu esse apoio, saiba que seu clique continua fazendo toda a diferença para nos manter no topo da pilha de prioridades.
A união aqui no fórum Diolinux Plus está provando que hardware funcional não é lixo eletrônico. Vamos continuar mostrando que temos voz técnica e força para melhorar o Linux para todos!
Clique aqui para apoiar e acompanhar: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2142389
Seguimos monitorando e lutando por cada frame dessas placas!
