Apoio à Comunidade: Vamos salvar as GPUs AMD R9 e RX da "aposentadoria forçada" no Linux?

Olá, pessoal! :waving_hand:
Estou passando para compartilhar uma pequena vitória técnica que, com a ajuda de vocês, pode se tornar o conserto definitivo para muitos usuários de GPUs AMD (arquiteturas Tonga e Polaris).
O Problema:
Identificamos uma regressão crítica a partir do Kernel 6.6 que causa travamentos, telas pretas e instabilidade no Wayland/X11, especialmente ao retornar da suspensão. Basicamente, placas perfeitamente funcionais (como a R9 380 e a série RX 400/500) estão se tornando instáveis em distros modernas como Ubuntu 24.04 e Zorin OS 18.
O Progresso Técnico:
Após 3 ciclos intensos de Git Bisect, conseguimos isolar o código exato que causou isso (o commit da1a055d). O nosso colega @sr_llucas até fez o teste de “força bruta”: instalou o Debian 12 com Kernel 6.1 e confirmou que o hardware está 100% saudável. O problema é, de fato, o software.
A Vitória Parcial:
Graças ao apoio inicial de alguns membros, o bug no Launchpad acaba de mudar para o status de “CONFIRMADO”! O sistema oficial do Ubuntu reconheceu que não é um caso isolado.
O Pedido (A Causa Justa):
Agora precisamos de “Calor” (Bug Heat). No Launchpad, quanto mais pessoas clicam que são afetadas, maior a prioridade que os desenvolvedores dão ao caso.
Mesmo que você não tenha essa placa, mas acredita que hardware funcional não deve virar lixo eletrônico por desleixo de software, peço humildemente o seu apoio:
Acesse o link do bug: Bug #2142389 “amdgpu (R9 380) fails to resume from suspend (deep...” : Bugs : linux package : Ubuntu
No topo da página, clique em: “This bug affects you and 1 other person” (ou algo semelhante com o ícone de um lápis amarelo).
Pronto! Você acabou de dar +4 pontos de relevância para essa correção.
Por que fazer isso?
Não é apenas pelas nossas placas. É para mostrar que a comunidade brasileira de Linux é organizada, técnica e não aceita que hardware bom seja descartado sem luta.
Agradeço imensamente ao @sr_llucas e ao @EntusiastaDeVelharia pelo apoio técnico até aqui. Vamos mostrar a força da nossa união! :penguin::flexed_biceps:

4 curtidas

:rocket: Atualização: Nossa mobilização está funcionando! (Status: CONFIRMADO)

Olá, pessoal!

Passando para compartilhar uma vitória técnica que está crescendo rápido e, com a união de vocês, pode se tornar o conserto definitivo para quem usa GPUs AMD das arquiteturas Tonga e Polaris.

O Problema (Em resumo): Uma regressão no Kernel 6.6+ está causando travamentos e telas pretas em placas como a R9 380 e a série RX 400/500. Hardware perfeitamente saudável está se tornando “instável” em distros modernas como Ubuntu 24.04, Zorin OS e Fedora, apenas por falha de software.

O Progresso Técnico: Isolamos o culpado! Após 3 ciclos intensos de Git Bisect, chegamos ao commit da1a055d. O @sr_llucas provou a saúde do hardware testando o Kernel 6.1, onde tudo funciona 100%. É um erro de “limpeza” de código que precisamos reverter.

Vitórias Atuais (Onde estamos):

  • Status: CONFIRMADO! O Launchpad oficial do Ubuntu já reconheceu que o problema é real.

  • Calor (Bug Heat): 26 pontos! :fire: Já rompemos a barreira inicial e estamos subindo no radar dos desenvolvedores.

  • União: Já somos 5 pessoas marcadas oficialmente como afetadas.

Um Agradecimento Especial: Quero agradecer imensamente ao Fernando Carneiro pelo apoio fundamental, além do suporte técnico contínuo do @sr_llucas e @EntusiastaDeVelharia. Essa rede de apoio é o que dá credibilidade ao nosso relatório.

O Pedido: Precisamos chegar ao menos em 30 de calor para ganhar prioridade máxima. Mesmo que você não tenha essa placa, seu clique ajuda a combater o lixo eletrônico e a obsolescência forçada.

  1. Acesse o link: Bug #2142389 no Launchpad

  2. No topo, clique em: “This bug affects you and 4 other people” (ícone do lápis amarelo).

Leva 10 segundos, mas para quem depende desse hardware para trabalhar ou estudar, esse clique vale ouro. Vamos mostrar que a comunidade é organizada, técnica e cuida do que é nosso!

Valeu pela força, pessoal! :penguin::flexed_biceps:

1 curtida

Não sei como devo ajudar mas informo que desde o kernel 6.8 usando uma rx580 até o atual 6.19 nunca tive absolutamente nenhum problema.

2 curtidas

Fala, @kalebepsouza! Que notícia excelente! É muito bom saber que sua RX 580 está segurando a onda no Kernel 6.19, isso reforça que o hardware é de guerra! :rocket:

Explicando o que está acontecendo: essa regressão é um pouco ‘sorrateira’. Ela depende de como a placa-mãe gerencia a energia (Deep Sleep) e do fabricante da GPU. No Kernel 6.1 o código era mais tolerante, mas a partir do 6.6 houve uma ‘limpeza’ no driver que acabou deixando algumas variações de placas instáveis.

Mesmo que tudo esteja bem aí, seu apoio é fundamental por dois motivos principais:

  • 1º Segurança Futura: Corrigir o código ‘raiz’ agora evita que essa falha evolua e acabe atingindo sua placa em versões futuras do Kernel. É um seguro para o seu hardware.

  • 2º Causa Comunitária: Precisamos de volume técnico (o chamado ‘Bug Heat’). Seu clique dá prioridade para que os desenvolvedores consertem o problema de quem hoje está com o PC travando ou com tela preta.

Se puder somar com a gente, o processo é bem simples, mas exige um login oficial por segurança:

  1. Acesse o link: Bug #2142389 no Launchpad.

  2. Login (Ubuntu One): No canto superior direito, clique em ‘Log in / Register’. É a conta padrão do ecossistema Ubuntu (a mesma usada para o Ubuntu Pro). Se não tiver, o cadastro é bem rápido.

  3. O Clique: Após logar, procure no topo da página (logo abaixo do título) um ícone de lápis amarelo onde diz: ‘Does this bug affect you?’. Clique ali e selecione ‘Yes, this bug affects me’.

Pronto! Com esses 10 segundos, você fortalece a comunidade e ajuda a provar que nossas RX ainda têm muita lenha para queimar. Valeu demais pela força! :penguin::flexed_biceps:

Acredito que a placa mãe possa ter muita culpa disso. Eu por exemplo utilizo um Machinist, que é uma versão genérica chinesa das antigas x99. Placas como a minha são cheias de limitações e bios mal implementada, principalmente a parte de ACPI. Porém, isso não é problema para o X11. E para o wayland também não era. Aparentemente virou um problema após o kernel 6.1 (não sei exatamente qual deles, pois testei somente o 5 e o 6.1). Acho que mais usuários podem experimentar o problema e creio que fizemos o certo ao alertar quem é de respeito. Se algo vai mudar ou não, cabe a quem é de direito escolher rsrsrs

1 curtida

Ponto certeiro, @sr_llucas! Você tocou na ferida: as implementações de ACPI em muitas BIOS (especialmente as X99 e outras mais antigas) sempre foram um campo minado.

O que acontece é que o Kernel Linux sempre teve ‘hacks’ e proteções para lidar com essas BIOS problemáticas. A nossa bisseção provou que, a partir do Kernel 6.6, houve uma tentativa de ‘limpeza’ nesse código que acabou removendo essas proteções para as GPUs Tonga e Polaris. O que antes o X11 ignorava, agora virou um ponto de falha crítico, especialmente no Wayland.

Fizemos o certo sim! O alerta já deu frutos: batemos 30 de calor (Bug Heat) no Launchpad e o status mudou para CONFIRMADO! :rocket:

Para quem está acompanhando o tópico: O relato do Lucas mostra que o problema pode estar ‘escondido’ esperando a combinação certa de hardware e Kernel. Se você usa GPUs AMD, mesmo que sua BIOS seja de marca famosa, seu apoio é o que garante que os desenvolvedores olhem para essa regressão com a seriedade que ela merece.

Como ajudar em 10 segundos: Se puder, dê aquele clique no ‘This bug affects me’ lá no Launchpad (link abaixo). Já somos um grupo forte de 5 usuários confirmados e cada novo apoio nos coloca mais perto da correção oficial.

:backhand_index_pointing_right: Bug #2142389 no Launchpad

Como o Lucas disse, o alerta está feito para ‘quem é de respeito’. Agora é manter o calor alto para que a solução venha por quem é de direito! Valeu demais pela parceria técnica, Lucas! :penguin::flexed_biceps:

Com certeza vou dar força a isso. Mas fiquei curioso sobre meu caso. Será que por a minha ser o modelo 2048SP não sofreria. Enfim, vou ajudar sim.

1 curtida

Qual distro vc está utilizando? E qual a sua placa mãe? Acho que é mt cedo para saber exatamente o que é. Pode ter haver desde hardware até bios da placa de vídeo, da placa mãe ou uma combinação. Mas certamente teve haver com alteração no kernel ou no módulo amdgpu

1 curtida

Machenist com Xeon. A distro atual é o cachyOS. Mas comecei usando Ubuntu 22.04 e dps Kubuntu 25.04 e ai hj o cachyos.

1 curtida

Acho que vou tentar. Vc usa cabo hdmi? Pq o meu tb eh machinist com xeon.

1 curtida

Sim. É um PC gamer.

1 curtida

Essa coincidência de setups entre vocês é sensacional! Machinist + Xeon é o combo de guerra de muitos de nós. @kalebepsouza, sobre a sua 2048SP: ela é uma Polaris legítima, mas o fato de você estar no CachyOS é um detalhe importante, já que eles aplicam correções de Kernel bem mais rápido que as distros convencionais. Valeu demais pelo apoio no Launchpad, sua ajuda foi essencial para o que vou contar agora!

@sr_llucas, sobre a conexão: no meu caso, eu utilizo DVI-D. Como meu monitor não tem áudio integrado, o DVI se mostra mais confiável por não ter que lidar com os protocolos de áudio e HDCP do HDMI, que às vezes engasgam na volta do suspend. E sim, também sou gamer, por isso essa estabilidade é sagrada para mim! Perder o progresso de um jogo porque o sistema não acordou do ‘sleep’ é frustrante demais.

A GRANDE NOTÍCIA: Pessoal, nossa mobilização aqui deu um resultado gigante: BATEMOS 34 DE CALOR (Bug Heat)! :fire:

Com essa pontuação, o bug ganha uma prioridade imensa na triagem do Ubuntu. Independentemente de usarmos HDMI ou DVI, CachyOS ou Ubuntu, nossa união provou que o problema é uma regressão real no código base.

Muito obrigado pela força, @kalebepsouza e @sr_llucas. Estamos documentando isso melhor que muito suporte oficial por aí! Seguimos na luta pelo fix definitivo. :penguin::video_game::flexed_biceps:

2 curtidas

Baixei a ISO do Ubuntu 22.04 que usa um Kernel mais antigo, vou aproveitar que a R9 380 está em produção e testar lá, ver se acontece algo. Estava pensando aqui que quando eu usava mais ela como minha placa principal, sempre tinha problema de voltar do suspend. O culpado também era meu ryzen primeira geração, que baixava demais a tensão em idle e acabava congelando a máquina. Será que era esse bug da AMD e eu nunca reparei nisso? Caraca. Detalhe que sempre usei ela no displayport.

Não sei mais quanto tempo essa 380 vai sobreviver, deixei ela no furmark um tempo e quando voltei a máquina tinha desligado, uma pena pois zerei até cyberpunk na pandemia nessa placa, guerreira. Espero que ainda dure mais um ou dois anos.

2 curtidas

Resolvi testar o CachyOS ontem, em modo live. Obtive o mesmo comportamento. Monitor vai dormir quando a sessão tenta entrar.

Testei o Mint com Wayland (kernel 6.14.0) (live-pendrive) e funcionou. Não fiz testes, mas o desktop estava normal e abriu aplicativos normalmente. Isso pode indicar que, no meu caso, o problema de kernel foi mais recente. O 6.17 (que é atualmente utilizado nas versões 24.04 do xUbuntu) não funciona.

1 curtida

Pessoal, essa troca de informações está ficando cada vez mais rica!

@EntusiastaDeVelharia, seu relato sobre o Ryzen de 1ª geração faz todo sentido. Muita gente achou que era instabilidade de hardware, mas nossa bisseção mostra que o driver vem ‘tropeçando’ na gestão de energia e o Kernel 6.6 apenas tirou a bengala que segurava o sistema. E olha, vida longa a essa sua R9 380!

Para você ter ideia da força dessa placa: eu estou jogando Resident Evil Requiem nela agora! Com um mix de configurações e os parâmetros certos na Steam (VKD3D_FEATURE_LEVEL=12_0 RADV_DEBUG=nodcc gamemoderun %command%), a bixinha ainda entrega uma experiência honesta. Ver esse hardware de 2015 rodando jogos de 2026 prova que ela não é ‘velharia’, é um hardware resiliente que só precisa de um software que não o abandone.

@sr_llucas, seu teste no CachyOS foi o ‘xeque-mate’. Como eles usam o que há de mais recente, isso prova que a regressão continua viva no código-base e não vai sumir sozinha. Isso valida 100% o nosso Git Bisect.

ESTAMOS QUASE LÁ: 38 DE CALOR! :fire::rocket: Já batemos 38 pontos no Launchpad. Estamos a apenas 2 cliques da marca histórica de 40 e podemos ir muito além ! Isso mostra para a Canonical e para a AMD que não estamos falando de hardware morto, mas de placas que ainda rodam Resident Evil, Cyberpunk e produzem conteúdo.

Quem puder somar nessa causa para salvar essas guerreiras, o link está na mão. Vamos mostrar que nossa comunidade sabe valorizar cada transistor!

:backhand_index_pointing_right: Apoie aqui: Bug #2142389 no Launchpad

Valeu demais pela força, time! :penguin::video_game::flexed_biceps:

Atualização.

No meu caso, a instabilidade parece ter tomado forma em versões mais recentes do kernel. Instalei o Ubuntu 24.04.3 LTS (que usa o kernel 6.14.0-27). A GPU funcionou normalmente, carregando aplicações gráficas e retornando da suspensão normalmente. Ao atualizar o mesmo sistema para o kernel 6.17, o sistema voltou a suspender vídeo. Vou adicionar esta informação no Launchpad.

1 curtida

Que aula de diagnóstico, @sr_llucas! Esse seu teste foi cirúrgico e o print que você postou é ouro puro para a nossa causa.

Ver o seu Xeon v4 com essa RX 570 rodando liso no Kernel 6.14, mas voltando a apresentar falhas no 6.17, é a prova cabal de que estamos lidando com uma ‘regressão sobre regressão’. Isso mostra que o problema é persistente e que a nossa investigação com o Git Bisect no Kernel 6.6 tocou na ferida exata do driver.

O que isso muda para nós: Essa informação é crucial. Ela prova aos mantenedores que o erro está infiltrado no código-base e precisa de uma atenção definitiva. Vou anexar esses detalhes ao relatório internacional para mostrar como o comportamento da GPU muda drasticamente entre essas versões do Kernel.

Status do Calor: Seguimos subindo! :fire::rocket: Graças a essa nossa mobilização e às novas evidências, o termômetro no Launchpad continua ganhando força: já batemos 38 de calor! Esse número é expressivo e mostra que o nosso relatório está ganhando uma visibilidade que a Canonical e a AMD não podem ignorar. Quanto mais gente somar, mais pressão faremos para que isso saia do papel.

@sr_llucas, se você puder subir esse print lá no Launchpad como anexo, dará um peso visual enorme ao caso. Ter um ‘antes e depois’ documentado assim é o que todo desenvolvedor de Kernel precisa para acelerar a correção.

Enquanto a solução oficial não sai, sigo aqui no meu ‘estaleiro técnico’, rodando meu Resident Evil Requiem na R9 380 com aqueles ajustes de performance. É gratificante ver que, com técnica e união, a gente consegue manter esse hardware guerreiro vivo, potente e produtivo.

Estamos fazendo um trabalho de triagem de alto nível! Valeu demais pelo esforço de testar essas versões, isso ajuda a comunidade inteira.

Gambiarra,

Consegui fazer funcionar no GNOME. Ainda não deu certo para o KDE.

Eu tive que desligar o modo “suspend” na BIOS, mudar o video para UEFI. Além disso, instalei a versão Ubuntu 24.04.3 LTS e atualizei manualmente após instalada.

É gambiarra para conseguir logar. Mas estou sem suspensão. Como não jogo, não me afeta, mas é um recurso a menos.

Vou tentar ver o KDE outro dia. Abs

1 curtida

É muito bacana receber esses selos! Além de reconhecer nossa presença, isso motiva a gente a contribuir cada vez mais com a comunidade. :trophy::fire:

Aproveitando esse emblema de Entusiasta, quero incentivar todos vocês: sempre que encontrarem um bug, não guardem para si, reportem! Nós, usuários finais, com nossas diversas combinações de hardware, somos os primeiros a sentir onde o sistema ‘dói’.

Um exemplo real é essa mobilização que estamos fazendo para salvar as GPUs AMD da série R9 e RX. Atualmente, o relatório está com 38 de calor e o apoio de vocês é o que faz a diferença para os desenvolvedores priorizarem o conserto:

:backhand_index_pointing_right: Apoie aqui: Bug #2142389 no Launchpad (Basta clicar em ‘This bug affects you’ no topo da página)

Contem comigo para apoiar os bugs que vocês reportarem também. Juntos, a gente garante que nosso hardware continue funcional e potente por muito mais tempo! :penguin::flexed_biceps:

Valeu pelo retorno, @sr_llucas! A ‘gambiarra’ é a mãe da sobrevivência no Linux, né? :joy:

O fato de você ter conseguido logar no GNOME desligando o suspend na BIOS e forçando o UEFI é um dado técnico valioso. Isso mostra que o Kernel está ‘engasgando’ justamente na transição de estados de energia (ACPI). Como o KDE (KWin) geralmente é mais exigente com certas extensões do driver AMD, faz sentido que ele ainda esteja apresentando resistência.

Para quem usa o PC para trabalho básico, essa solução quebra o galho, mas como você disse: é um recurso a menos. Para quem joga ou precisa de eficiência energética, o suspend é vital. Eu sigo aqui ‘espremendo’ a R9 380 com o meu Resident Evil Requiem e monitorando o relatório.

Status do Movimento: Mesmo com as soluções paliativas, o nosso foco continua sendo o conserto na raiz. O relatório no Launchpad segue firme em 38 de calor e a sua persistência em testar essas alternativas ajuda a documentar o que funciona (e o que não funciona) enquanto o patch oficial não vem.

Se conseguir algo no KDE, avisa a gente! Abs e parabéns pelo emblema de Entusiasta também, essa constância aqui no fórum é o que faz a comunidade crescer! :penguin::flexed_biceps: