# Quedas de GPU, testes e o que resolveu no meu PC

Meu PC rodava os jogos bem e, do nada, perdia o vídeo ou reiniciava. Depois de dias investigando hardware e software, encontrei um cabo aquecendo na alimentação elétrica da casa. Corrigi a instalação/tomada e as quedas pararam. Esse foi o conserto no meu caso.

A máquina é um Ryzen 7 5800X, Gigabyte X570 AORUS PRO WIFI rev. 1.1, XFX RX 9070 XT Swift e fonte Corsair HX850. A investigação passou por Windows e Ubuntu.

Os jogos rodavam lisos até a falha. Aconteceu em Crimson Desert, Like a Dragon: Infinite Wealth e Assassin’s Creed Black Flag Resynced. Às vezes o vídeo sumia, mas o áudio continuava e o Num Lock respondia. Em outras ocasiões a máquina reiniciava. Também tivemos WHEA 0x124 no Windows e Machine Checks no Linux ao longo da investigação.

O que fizemos:

- Testes de memória, OCCT, FurMark e uso combinado de CPU/GPU/VRAM. Houve testes aprovados e sessões estáveis, mas as falhas voltavam nos jogos. Nem todos os testes tinham duração e resultado detalhados salvos.
- RAM sem XMP, com XMP e também em 3800 MHz/1,4 V durante as tentativas.
- Ajustes de boost e Curve Optimizer da CPU. Reduzir o teto de boost ajudou a conseguir boot em uma etapa. CO positivo +7 ainda falhou no OCCT, com MCE registrado; depois passamos por +10 e chegamos a +12.
- BIOS F40c conferida e microcode AMD instalado e carregado. Os MCEs foram examinados por boot e núcleo; apareceram principalmente nos núcleos físicos 6 e 7.
- ReBAR ligado e desligado. As quedas ocorreram nas duas condições.
- Redução de clock da GPU. As quedas continuaram com −250 MHz e também com −420 MHz/limite de 315 W. Esses resultados ficaram registrados em logs, com os ajustes conferidos no LACT e no driver.
- Conferência de temperaturas, potência e link PCIe. A placa estava em Gen4; uma RX 6900 XT havia funcionado no mesmo slot por quase dois anos. Gen3 chegou a ser proposto, mas não foi testado.

No Linux, uma das sequências de erro foi:

```text
device lost from bus!
TransferTableSmu2Dram ... response:0xFFFFFFFF
ring gfx_0.0.0 timeout
GPU Recovery Failed: -19
```

A perda de comunicação com a GPU aparecia antes do timeout e da tentativa de recuperação. Conferimos inclusive o código do driver que emite a mensagem: a leitura da configuração PCI estava falhando. O nome do jogo aparecia no log, mas isso sozinho não explicava por que a placa tinha deixado de responder.

Também houve uma investigação separada do Crimson Desert no Proton. Nesse caso, o jogo nem chegava à partida: caía na preparação das sombras com uma leitura de ponteiro nulo (`0xc0000005`, endereço `0x30`).

Comparamos o VKD3D Stable oficial, uma compilação local sem alterações e uma compilação com um backport de View Instancing. Mantivemos a mesma base do Proton Experimental e trocamos o par de DLLs D3D12. As duas versões Stable reproduziram o crash; a versão com o patch abriu e chegou à jogabilidade. O Proton Experimental completo também funcionou no teste. Analisamos dump, assembly, a busca do passe `SceneCharacterShadowBindless0` e os hashes dos binários. A compilação com patch também mudou a identificação usada pelo cache, então o teste não isolou completamente o efeito do patch.

Esse estudo está publicado, com patch e reprodução: [relatório técnico do Crimson Desert](https://crimson.eclusa.dev/). O estudo original trata do crash de inicialização; a atualização de 18/09 acrescenta o desfecho da instalação elétrica.

O que resolveu as quedas durante o uso foi mexer na alimentação **da casa**. Encontrei cabo quente, desliguei o disjuntor e fiz o reparo na instalação/tomada. Estou falando da parte externa ao computador, não dos cabos internos da fonte. Depois disso, o PC ficou estável, inclusive com jogo em background e alternando entre jogo e outros aplicativos.

O perfil que mantive foi **Curve Optimizer +12 e memória com XMP a 1,39 V**. Esses são os valores da minha máquina, não uma receita para copiar. Como houve ajustes de CPU e RAM ao longo do caminho, não atribuo automaticamente todos os WHEA/MCE antigos ao cabo.

Estou compartilhando porque passei dias procurando a explicação dentro do PC. No meu caso, o problema que restava estava na instalação que alimentava ele. Um timeout de GPU, por si só, não identifica qual peça precisa ser trocada.

Relato consolidado em 18/09/2026, a partir dos testes, logs e reparo relatado por Nathan.