Como rastreei e corrigi os travamentos de suspensão e retomada no Linux com GPU AMD

 (nyanpasu64.gitlab.io)
1 pontos por GN⁺ 2025-02-18 | 1 comentários | Compartilhar no WhatsApp
  • Em um desktop Linux com AMD RX 570, ao suspender com alto uso de RAM, após a retomada o sistema repetidamente ficava com tela preta ou sem aceitar entrada, o que exigiu rastrear não só um problema de vídeo, mas todo o fluxo de gerenciamento de energia do kernel
  • A causa principal estava no fluxo em que o amdgpu, que precisa fazer backup da VRAM na RAM do sistema antes da suspensão S3, não conseguia usar corretamente o swap em disco quando havia pouca RAM livre e acabava quebrando por OOM
  • O primeiro patch, que adiantava a eviction da VRAM de dpm_suspend() para dpm_prepare(), reduziu a disputa com o desligamento de energia do SSD, mas como pm_restrict_gfp_mask() já havia desativado o swap, ainda podia ocorrer falta de memória contígua
  • Depois, ao mudar para chamar amdgpu_device_evict_resources() no momento de PM_SUSPEND_PREPARE com register_pm_notifier(), passou a ser possível fazer backup da VRAM enquanto swap e disco ainda estavam ativos, e no ambiente de testes a suspensão funcionou mesmo com alto uso de RAM e VRAM
  • Essa mudança foi mesclada na árvore do amdgpu, mas acabou revertida em 2025-06 por causa de uma possível condição de deadlock; em caminhos de suspensão que não congelam primeiro os processos de usuário, apps 3D podem puxar a VRAM de volta para a GPU e impedir a eviction

Falhas repetidas na suspensão e o diagnóstico inicial errado

  • O desktop tinha configuração de dual boot com Windows e Linux, e ao tentar suspender no Linux com alto uso de RAM, o sistema frequentemente quebrava
    • Após retomar, aparecia só uma tela preta com cursor móvel, ou então não havia saída de vídeo nenhuma e apenas magic SysRq ou reset físico funcionavam
    • Em alguns casos, o relógio da tela de bloqueio do KDE continuava atualizando em tempo real, mas travava ao tentar fazer login ou interagir
  • O ambiente de testes era Gigabyte B550M DS3H, GPU AMD RX 570, SSD NVMe Kingston A2000 1TB, Arch Linux, systemd-boot e Linux 6.4
  • Ao verificar os logs da inicialização anterior com journalctl --system -b -1, apareceram erros de OOM em código do kernel sob amdgpu_device_suspend em algumas tentativas de suspensão
  • Muitos casos de falha terminavam nos logs abaixo, sem registro de que o sistema quebrado tivesse voltado a acordar
    • systemd-sleep: Entering sleep state 'suspend'...
    • kernel: PM: suspend entry (deep)
  • No começo, a suspeita recaiu sobre o modo de economia de energia NVMe APST, então foram testados nvme_core.default_ps_max_latency_us=0, iommu=soft, upgrade de firmware do SSD e até troca do SSD de boot de 2 TB, mas nada resolveu

Ferramentas de depuração que ajudaram a reduzir o escopo da falha

  • Como o systemd pode tentar vários modos de suspensão em sequência, gerando ruído nos logs e piorando o estado do kernel, foi adicionado SuspendState=mem em /etc/systemd/sleep.conf
    • Isso simplificou a depuração, mas não resolveu a causa raiz
  • Foi usado echo 1 > /sys/power/pm_trace para rastrear onde a suspensão falhava
    • pm_trace grava o estado de progresso da suspensão e retomada no relógio do sistema
    • Graças ao efeito colateral de desativar a suspensão assíncrona, também foi possível observar casos em que, após falha no suspend do amdgpu, o sistema se recuperava em vez de travar por completo
  • Foi adicionado o parâmetro de kernel systemd.debug_shell para abrir um shell root em Ctrl-Alt-F9 sem precisar fazer login no KDE ou em um TTY
  • Como às vezes o controlador USB e o teclado quebravam, foi usado um teclado PS/2 e depois configurado um console serial
    • Parâmetros de kernel: no_console_suspend console=tty0 console=ttyS0,115200 loglevel=8
    • Em um notebook, os logs eram capturados continuamente com sudo minicom --device /dev/ttyUSB0 --baudrate 115200
    • O console serial permitia executar comandos e coletar logs mesmo depois que vídeo e rede falhavam, embora tivesse limitações de velocidade de transmissão e de cores/tamanho de tela

A relação entre eviction de VRAM no amdgpu e OOM

  • Os logs de crash geralmente apontavam para o caminho de eviction de buffers TTM do amdgpu
    • amdgpu_device_evict_resources()
    • amdgpu_ttm_evict_resources()
  • Em relatórios de bug relacionados, confirmou-se que “evict” estava ligado a copiar a VRAM para a RAM do sistema ou mover a RAM do sistema para o swap
  • Quando o desktop entra em suspensão S3, a energia da GPU PCIe é cortada e os dados nos chips de VRAM se perdem
    • O driver da GPU precisa copiar para a RAM do sistema a VRAM em uso antes da suspensão
    • Depois da retomada, precisa restaurar novamente os dados salvos na RAM
  • O driver amdgpu do Linux tinha um problema: quando não havia RAM livre suficiente para guardar toda a VRAM em uso, em vez de mover a RAM do sistema para swap em disco, ele podia cair por falta de memória
  • Quando o Linux encontra OOM durante a suspensão, tenta cancelar a suspensão e reinicializar os dispositivos, mas como a suspensão já foi parcialmente interrompida, alguns drivers podem ficar quebrados ou ocorrer novo OOM durante suspend/resume
    • O risco aumenta quando a suspensão assíncrona está ativada
    • A própria suspensão pode até ter dado certo, mas o OOM pode surgir ao iniciar os dispositivos durante a retomada

Primeira tentativa de correção: adiantar o momento do backup da VRAM

  • Mario Limonciello sugeriu ativar /sys/power/pm_print_times e /sys/power/pm_debug_messages e verificar os logs da suspensão
  • Os logs mostraram que os drivers NVMe e amdgpu entravam em pci_pm_suspend em paralelo durante a suspensão
  • No começo, a ideia foi descobrir como fazer a suspensão da GPU acontecer antes da suspensão do SSD, e também foi analisado o mecanismo de ordenação de suspensão de dispositivos do Linux
    • Esse mecanismo parecia mais adequado para sincronizar periféricos intimamente conectados do que para suspender todas as GPUs antes de todos os discos do sistema
  • Mario propôs fazer a eviction da VRAM na fase prepare da suspensão do Linux e escreveu um patch de kernel movendo a eviction de VRAM de dpm_suspend() para dpm_prepare()
  • O fluxo antes e depois da mudança ficou assim
    • Antes: o backup da VRAM acontecia em dpm_suspend(), podendo coincidir com o desligamento do SSD
    • Depois: o backup da VRAM era tentado antes em dpm_prepare(), e em caso de falha a suspensão era abortada antes da suspensão dos demais dispositivos
  • A mudança foi melhor do que antes, mas ainda falhava com alto uso de RAM porque pm_restrict_gfp_mask() desativa o swap antes de dpm_prepare()
    • amdgpu_ttm_evict_resources() ainda podia falhar por falta de memória contígua
    • Mesmo colocando toda a VRAM na RAM, se depois não sobrasse espaço para as alocações do driver, ainda podia ocorrer OOM durante sleep ou wake

Um crash separado do amdgpu encontrado com Ghidra

  • Durante os testes, ocorreu o erro BUG: unable to handle page fault for address: fffffffffffffffc, que parecia uma dereferência de ponteiro quase nulo
  • O log do crash apontava para dm_resume+0x200, mas não fornecia o número da linha no código-fonte
  • Depois de salvar e extrair o módulo de kernel amdgpu.ko, ele foi decompilado com Ghidra para mapear a posição do crash em dm_resume à linha correspondente no código do kernel
  • O problema aparecia no macro for_each_new_crtc_in_state(dm->cached_state, crtc, new_crtc_state, i)
    • dm->cached_state não era um ponteiro válido, e sim fffffffffffffff4
    • Em seguida, ao ler o campo [RSI + 0x8], ocorria um page fault no endereço fffffffffffffffc
  • A causa estava no fluxo em que dm_suspend() armazenava diretamente em um ponteiro o valor retornado por drm_atomic_helper_suspend()
    • drm_atomic_helper_suspend() pode retornar um ponteiro válido ou ERR_PTR(err)
    • Por causa de OOM, foi retornado -ENOMEM (-12), e o código de suspend do amdgpu aparentemente dereferenciou isso como se fosse ponteiro
  • Mario corrigiu esse problema adicionando verificação do valor de retorno com falha e abortando a suspensão

Caminho abandonado: permitir swap durante prepare()

  • A razão de a suspensão continuar falhando com alto uso de RAM era que o amdgpu fazia backup da VRAM em dpm_prepare(), mas nesse momento pm_restrict_gfp_mask() já havia desativado o swap em disco
  • Uma tentativa foi permitir swap durante dpm_prepare() e só desativá-lo em dpm_suspend(), imediatamente antes de desligar os discos
  • Para isso, foi feito um experimento movendo a chamada de pm_restrict_gfp_mask() de enter_state() para mais fundo, dentro de dpm_suspend_start()
  • Havia várias limitações práticas
    • pm_restrict_gfp_mask() é declarada em kernel/power/power.h e chamada em kernel/power/suspend.c
    • O local onde se queria chamar a função era drivers/base/power/main.c, arquivo que normalmente não inclui headers de kernel/power/
    • Como hack temporário, foi adicionado #include <../kernel/power/power.h>, mas seria difícil justificar essa estrutura upstream
  • Também havia problemas de correção com suspensão híbrida
    • A suspensão híbrida salva a imagem do sistema, chama pm_restrict_gfp_mask() e depois chama suspend_devices_and_enter() com o swap ainda desativado
    • Chamar a mesma função novamente gera warning e pode impedir que pm_restore_gfp_mask() reative o swap corretamente
  • Nos testes, a frequência de falhas ou crashes caiu, mas o problema não foi totalmente resolvido, e como era uma mudança frágil no core de gerenciamento de energia, não foi tentado upstream

Solução alternativa em espaço de usuário: amdgpu-sleep

  • Em 2024-10, após fechar o SuperTuxKart e suspender, ao retomar apareceu uma tela preta
    • Pelos logs, a primeira tentativa de suspensão falhou por OOM em dpm_prepare(), e a tentativa seguinte terminou em crash de alocação de memória do amdgpu em bw_calcs() durante a retomada
  • A inspiração veio do método de backup de VRAM em espaço de usuário da NVIDIA
    • A NVIDIA faz o backup e a restauração da VRAM escrevendo em /proc/driver/nvidia/suspend a partir de serviços executados pelo systemd antes e depois de chamar a suspensão do kernel
  • Com base nisso, foi criado o pacote amdgpu-sleep para Arch Linux
    • Antes da suspensão, ele lê /sys/kernel/debug/dri/1/amdgpu_evict_vram
    • Esse endpoint de debug manda o amdgpu salvar toda a VRAM na RAM do sistema
    • O systemd espera a eviction da VRAM terminar antes de iniciar a suspensão do kernel
  • Ao suspender o desktop, o sistema rapidamente copiava a VRAM para a memória e, quando necessário, empurrava a RAM para o swap, conseguindo funcionar
  • Quando vários apps 3D estavam rodando, porém, eles continuavam renderizando frames e puxando a VRAM de volta para a GPU, causando um livelock de cabo de guerra com amdgpu_evict_vram
    • Esse estado podia durar mais de 70 segundos até amdgpu_evict_vram desistir
    • Depois disso, o systemd iniciava a suspensão do kernel e, ao congelar o userspace, a eviction de VRAM conseguia dar certo na fase do kernel
  • O script continuou sendo usado porque a frequência do livelock não era menor do que a frequência dos crashes em nível de kernel quando o script era desativado

Patch final: notifier de gerenciamento de energia

  • Em 2024-11, Mario pediu testes de um patch que permitia eviction enquanto o swap ainda estava ativo
  • O patch usava register_pm_notifier() e a API de power management notifier do Linux
  • O callback recebia as mensagens PM_HIBERNATION_PREPARE e PM_SUSPEND_PREPARE e chamava amdgpu_device_evict_resources()
  • PM_SUSPEND_PREPARE é emitido em enter_state() → suspend_prepare() por meio de pm_notifier_call_chain_robust(PM_SUSPEND_PREPARE, PM_POST_SUSPEND)
    • O PM_SUSPEND_PREPARE é entregue aos drivers que têm callback de notifier
    • Se ocorrer falha, os drivers já preparados recebem PM_POST_SUSPEND e a suspensão é abortada
  • Ao fazer a eviction da VRAM nesse ponto, pm_restrict_gfp_mask() ainda não desativou o swap e os discos também ainda não foram congelados
  • O fluxo corrigido ficou assim
    • suspend_prepare()
    • PM_SUSPEND_PREPARE
    • amdgpu_device_pm_notifier() → amdgpu_device_evict_resources()
    • pm_restrict_gfp_mask()
    • dpm_prepare()
    • dpm_suspend()
  • Depois de compilar um kernel customizado com o driver amdgpu modificado e testar, várias suspensões com alto uso de RAM e VRAM passaram sem erro
  • Houve, porém, um efeito colateral: como o amdgpu fazia backup da VRAM antes de o PipeWire ou o kernel silenciarem os alto-falantes, o áudio ficava repetindo por alguns segundos
  • Após algumas rodadas de revisão de código, a mudança foi mesclada na árvore do amdgpu, levando finalmente à correção desse bug após mais de um ano de tentativas

Atualização de 2025-06 e reversão

  • No começo, esperava-se que a mudança entrasse no stable Linux kernel 6.14, mas depois ela foi revertida por causa de um possível deadlock
  • O novo problema acontece quando o systemd chama a suspensão do sistema sem primeiro congelar todos os processos de usuário
    • O kernel tenta fazer eviction da VRAM para a RAM do sistema antes de congelar os próprios processos
    • Ao mesmo tempo, se um programa 3D puxar a VRAM de volta para a GPU, o processo de eviction durante a suspensão pode entrar em deadlock
  • Isso é parecido com o livelock observado na solução alternativa em espaço de usuário com amdgpu_evict_vram
  • O mantenedor de PM do Linux sugeriu mover a chamada de pm_restrict_gfp_mask() para dentro de suspend_devices_and_enter()
    • Isso se conecta à direção já experimentada antes, de permitir swap durante prepare()
  • Não há plano de implementar e enviar isso diretamente
    • A GPU AMD foi movida para um computador antigo com CPU mais lenta e 8 GB de memória, e nesse ambiente não há vontade de compilar kernels
  • O computador principal foi atualizado para uma Intel Arc B570, mas o mesmo tipo de problema ocorreu também com 10 GB de VRAM
    • O caso foi reportado no bug tracker de kernel drm/xe

Leituras relacionadas

1 comentários

 
GN⁺ 2025-02-18
Comentários do Hacker News

  • A suposição de que a alimentação da GPU PCIe é cortada quando um desktop entra em suspensão S3 não é tão certa
    É verdade que o S3 corta toda a energia exceto a da RAM, mas, por exemplo, placas-mãe Gigabyte Aorus são notórias por um bug de suspensão em SSDs NVMe que impede o sistema de dormir ou acordar corretamente
    Em geral, dá para contornar com uma regra udev que bloqueia o wake-up em todas as portas PCIe: ACTION=="offline", SUBSYSTEM=="pci", DRIVER=="pcieport", ATTR{power/wakeup}="disabled"
    De forma mais restrita, dá para especificar só a porta PCIe problemática, como em ATTR{vendor}=="0x8086", ATTR{device}=="0x43bc", e encontrar a causa com /proc/acpi/wakeup, /sys/class/pci_bus/*/*/yourWakeupDevicePci/uevent | grep PCI_ID, udevadm info --attribute-walk /dev/whatever
    Em vez de udev, também é possível alternar /proc/acpi/wakeup em um serviço systemd ou script de automação, mas é menos confiável; esses problemas de suspensão no Linux são realmente exaustivos

    • Na minha placa-mãe, tive que colocar ACTION=="add", KERNELS=="0000:00:01.1", ATTR{power/wakeup}="disabled" em /etc/udev/rules.d/ para impedir despertares espontâneos
      O receptor Logitech Bolt também acorda imediatamente vários computadores Linux, mas não sei por que isso não acontece no Windows; também não está claro se, para tentar capturar USB, eu precisaria de um analisador lógico ou de um equipamento como o Glasgow
      Como solução temporária, adicionei a regra ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c548", ATTR{power/wakeup}="disabled" para bloquear isso
    • Acho que perdi alguns kWh por causa desse problema em uma placa-mãe Aorus, então estava esperando uma solução, mas no meu caso não funcionou
    • Eu também vinha enfrentando problemas de suspensão em uma X570 Aorus Master, e resolvi executando echo GPP0 >> /proc/acpi/wakeup em uma unidade systemd na inicialização
      Porém, a primeira suspensão após o boot sempre acordava imediatamente; ao aplicar a regra udev acima, parece que esse problema também foi resolvido
    • Dá vontade de esperar que seja possível detectar se o hardware de fato entrou em suspensão, ou que acordar novamente um hardware que não chegou a dormir não cause problemas
      Parece que deveria ser possível enviar um comando de suspensão a um dispositivo PCIe e depois colocar o próprio barramento para dormir; ao acordar, reativar primeiro o barramento e só então acordar o dispositivo
    • Sofri por um tempo com esse problema, mas esse método também não funcionou; o que organizei está em https://bbs.archlinux.org/viewtopic.php?id=302440
      No meu caso, a causa do wake-up parece vir de .../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:45/wakeup/wakeup6, mas não sei muito bem o que esse caminho significa

  • Como autor do memreserver, uma das soluções alternativas em espaço de usuário mencionadas, depurei esse problema alguns anos atrás
    O comentário público que consigo encontrar rapidamente é https://gitlab.freedesktop.org/drm/amd/-/issues/2125#note_17..., e lembro que também houve uma discussão em mailing list
    O ponto principal era que o Linux não tinha hooks de suspend em etapas que fossem executados de forma confiável antes que o disco e partes do subsistema de memória fossem congelados; agora isso parece ser possível
    Infelizmente, o GitLab do Freedesktop parece não ser bem indexado, então esse conhecimento acabou ficando enterrado

  • Um trabalho realmente excelente
    Se você já se perguntou por que é difícil fazer a transição para suspensão funcionar corretamente no Linux, e por que também é difícil depurar isso, este texto por si só mostra muito bem quantos pontos podem quebrar
    Até hoje, no ThinkPad P1G4, se eu não desligar manualmente a ventoinha antes de suspender, ela não desliga sozinha; recentemente, depois de voltar da suspensão, também passei a ter ruído em fones Bluetooth e precisei desativar a suspensão de nós do PipeWire: https://wiki.archlinux.org/title/PipeWire#Noticeable_audio_d...

    • É impressionante que, mesmo em 2025, sleep/suspend em notebooks Linux ainda não funcione direito
      A primeira vez que encontrei esse tipo de problema deve ter sido uns 15 anos atrás
    • Suspensão é realmente uma loteria, e erros como os descritos no texto são muito difíceis de depurar
      Entre as soluções de contorno sugeridas para vários problemas, algumas envolvem desativar modos de economia de energia; como o objetivo de usar suspensão normalmente é aumentar a autonomia da bateria, essa abordagem não é muito realista, pois pode reduzir bastante o tempo de uso real
      Ainda assim, não é impossível fazer a suspensão S0ix funcionar
      Instalei Arch Linux em portáteis baseados em AMD 7840U e AMD 8840U, ou seja, GPD Win Max 2, GPD Win Mini, GPD Win 4, Minisforum V3 e OneXPlayer X1 Ryzen, e parece improvável que essas empresas tenham projetado ou testado os aparelhos pensando em suporte a Linux
      Mesmo assim, apenas ajustando um pouco fontes falsas de despertar em /proc/acpi/wakeup e /sys/devices/*/*/*/power/wakeup, consegui suporte a S0ix quase perfeito, exceto no OneXPlayer X1 Ryzen mais recente
      O suporte do kernel Linux padrão também é ótimo: touchscreen, entrada por caneta, Wi-Fi e Bluetooth funcionam bem, e a única lacuna que vi foi o suporte ao leitor de digitais
      Esses fabricantes menores fazem menos customização extrema de componentes e menos integração minuciosa, algo que na prática aparece em aparelhos alguns milímetros mais grossos
      Por isso, eles acabam escolhendo componentes mais conservadores, e o resultado pode ser um suporte a Linux surpreendentemente bom
    • Para o usuário final conseguir usar suspensão facilmente e bem, a resposta é comprar hardware com compatibilidade validada
      Pela minha experiência, em ThinkPads corporativos isso é muito estável há muito tempo, e usuários de Windows do mesmo modelo parecem, na verdade, sofrer com problemas de suspensão com mais frequência

  • Pessoalmente, sou muito grato
    Meu notebook principal é um ThinkPad com Ryzen rodando Linux, e uso suspensão e hibernação com frequência; vinha encontrando esse problema de forma intermitente
    Estou ansioso pelo Linux 6.14

  • O motivo de dm->cached_state ter armazenado -12 em vez de um ponteiro provavelmente é que, durante o suspend, dm_suspend() atribuiu diretamente dm.cached_state = drm_atomic_helper_suspend(adev_to_drm(adev))
    A função chamada, drm_atomic_helper_suspend(), pode retornar um ponteiro válido ou um ERR_PTR(err) que codifica um erro como ponteiro negativo; o chamador colocou isso diretamente no ponteiro sem verificar erro e depois o desreferenciou no resume
    Mais um motivo para colocar Rust no kernel: se o tratamento do tipo Result fosse obrigatório, seria difícil esse tipo de coisa acontecer

    • Também dá para criar tipos soma algébricos com o pré-processador de C: https://github.com/Hirrolot/datatype99
      Mas os padrões importam, e o histórico do kernel de adiar por muito tempo a modernização das práticas de codificação joga contra melhorias no lado do C
      Ironicamente, essa mesma resistência também frustra desenvolvedores Rust, porque nem mesmo organizar cada subsistema ou documentar como ele funciona costuma ser bem aceito
      Algo como https://github.com/llvm/llvm-project/issues/74205 chegando até o kernel poderia ajudar, mas ainda assim acho que continuariam preferindo sobrecarregar ponteiros manualmente em vez de obter segurança pelo sistema de tipos

  • Uso dual boot Linux/Windows em um notebook Framework AMD com módulo de expansão de GPU, então acho que esse trabalho vai ajudar
    Gostaria de apoiar diretamente ou doar para uma instituição de caridade de preferência; o contato está no perfil

  • Eu achava que nomear coisas, invalidação de cache e erros off-by-one eram os dois maiores problemas da ciência da computação, mas, depois de conhecer os problemas de sleep/wake, isso parece NP-completo

    • Vejo sleep/wake como um subconjunto de invalidação de cache
      Se todos os periféricos não tivessem estado, provavelmente não seria um problema
    • Só no Linux; no Windows é O(n²), no macOS é O(log n)

  • No Linux, o gerenciamento de memória — especialmente em situações de OOM — ainda é um pesadelo incrivelmente doloroso
    Não é que eu passe por esse tipo de problema o tempo todo, mas certamente já tentei depurar problemas parecidos e falhei; no fim, quando dá OOM, normalmente acabo colocando mais RAM
    É desperdício e é caro, mas lidar de forma elegante com situações de OOM parece ser um problema que o Linux ainda terá dificuldade para resolver por muito tempo
    Este trabalho foi excelente e deve servir como referência para depurar problemas semelhantes no futuro
    Também achei ótimo o recurso debug-shell do systemd; nem sabia que isso existia
    Só que minha placa X670E Steel Legend parece não ter header serial, então fico curioso sobre como portas seriais onboard funcionam hoje em dia
    Será que ficam ligadas às lanes PCIe do chipset?
    Ao mergulhar no kernel Linux, gravações de palestras sobre subsistemas do kernel em eventos como FOSDEM ou Linux Plumbers Conference ajudam muito; por exemplo, o vídeo sobre o subsistema de memória TTM, usado pela maioria dos drivers DRM de GPUs de desktop, é este: https://www.youtube.com/watch?v=MG7_tUNKSt0

    • No Windows, a porta serial da minha placa-mãe aparece conectada a Pci Bus → PCI standard ISA bridge
      Viva o DOS
      Vou assistir ao vídeo sobre TTM quando tiver tempo
    • Conter OOM com cgroups tem funcionado bem
      Não sei bem se existe uma forma moderna de tratar OOM melhor do que a que o Linux faz; se houver algum material relacionado que valha a pena ler, gostaria de saber
    • Sim, é horrível, para dizer o mínimo
      O Linux não lida direito com situações de OOM
      Sei que dá para colocar guardrails com cgroups, instalar earlyoom, aumentar o swap ou usar zram
      Mas, no fim, tudo isso não passa de gambiarras sujas que podem salvar você uma vez ou outra; não corrigem a forma como essas situações são tratadas
      Gostaria que essas coisas não fossem apresentadas como soluções
      Já vi o kernel não conseguir alocar memória em dm_crypt e um volume LUKS se montar sozinho como somente leitura; pelo amor, bastava matar um processo em espaço de usuário
      O estado atual é simplesmente inaceitável, e já estou cansado das desculpas
    • Fico curioso se você já tentou usar zswap/zram
      Com zstd, dá para usar 8 GB de RAM como se fossem 20 GB de “RAM”, ou 16 GB como 40 GB, sem grandes problemas
      Indo mais longe, também dá para fazer overcommit de memória acima de 100%; o Android também faz isso, então é uma abordagem bastante estável

  • Boa notícia
    Os drivers gráficos da AMD para Linux geralmente funcionaram bem para mim, mas esse problema foi uma exceção que encontrei várias vezes

    • Eu tive um pouco menos de sorte
      O problema que venho enfrentando recentemente é que, depois de acordar da suspensão, o driver fica despejando no log WARNING: CPU: 12 PID: 11871 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:100 generic_reg_update_ex+0x1d2/0x290 [amdgpu] seguido de "[drm] scheduler comp_1.0.n is not ready, skipping"
      https://gitlab.freedesktop.org/drm/amd/-/issues/3911
    • Minha experiência também é boa no geral, mas acontece um problema parecido se eu desconecto o Thunderbolt ao qual o monitor está ligado enquanto o dispositivo está dormindo
      Mas, como é um notebook, a configuração dos drivers é bem diferente e não há GPU PCIe

  • A parte em que salvaram e extraíram o módulo de kernel amdgpu.ko, decompilaram com o Ghidra e então mapearam o ponto de crash em dm_resume para a linha correspondente no código-fonte do kernel é sempre a minha cena favorita em depuração