Sistema congelando

Venho enfrentando congelamentos no sistema aleatóriamente. A interface gnome trava e nem consigo acessar outros tty. O kernel parece ainda estar funcionando, pois o led do Caps ainda muda.
Acho que pode ter relação com o update no microcode contra o gds (7200u). Fedora 38 e Alma 9.
Alguém mais vem enfentando esse problema?

Meu Ubuntu 23.04 estava dando umas congeladinhas de leve, até que ontem ele congelou totalmente. O vídeo que eu estava vendo continuou rodando normalmente, mas eu não conseguia acessar a tty. Foi aí que eu pensei em ir para o KDE Plasma porque eu estava considerando que o problema era com o Gnome.

Uso Intel também…

1 curtida

Boa tarde

Não será isso problema com a memória com defeito ou suja ?

Passa um teste de memórias no boot tipo o Memtest86+

1 curtida

Aqui também continua rodando o audio.

Provável que não, no Windows ( acho que não foi feito update ainda) não trava.

Você já tentou configurar a tecla SysRq? Você precisa adicionar em /etc/sysctl.conf:

kernel.sysrq = 1

Reiniciar ou rodar sudo sysctl -p. Com isso, quando congelar você pode tentar usar o atalho Alt (talvez Alt + Fn, depende da máquina) + PrtScn/SysRq, assim você pode tentar:

Alt + SysRq + F → mata o processo principal, pode te ajudar a chegar em um terminal
Alt + SysRq + m → pode ser útil também na hora do congelamento, para verificar o uso de memória

antes disso, você pode dar uma olhada no que aconteceu perto do fim do seu boot anterior:

# coloque --dmesg se você suspeita que é algo do lado do kernel:
journalctl -b -1 -xe

a tecla SysRq tem vários usos, se F não ajudar, pode usar REISUB para fazer o melhor reboot possível nesse caso:

r - remove o teclado do X/Wayland.
e - envia SIGTERM para todos os processos.
i - envia SIGKILL para todos os processos.
s - sync todos os discos montados.
u - Remonta os mesmos em modo leitura.
b - reboot.

2 curtidas

Fazendo isso ele mata o xwayland e volta para o gdm.
O sistema trava quando fecho o navegador após ver vídeos no youtube e clico no botao atividades.
Não aparece nenhum erro no journalctl.

Alguém sabe como descobrir a raiz do problema? Desse jeito fica impossível usar o Linux.

Rapaz, agora eu estou no KDE Plasma e com ele não tive mais problemas desse tipo como estava tendo antes no GNOME.

Não faça uma busca simplista por termos como error ou coisas assim, pode ser útil usar termos como gpu, gnome, etc. Você vai precisar dar uma boa vasculhada nas proximidades do ocorrido.

Também pode ser um problema de falta de recursos, pode ser interessante investigar a evolução do uso de memória, como mencionei lá em cima. Um loop com algum destes pode ajudar:

top -b -n 1 >> recursos.txt
free -h >> mem.txt

A partir daqui, as técnicas de investigação variam, dependendo do hardware, etc. Por exemplo, quem tem NVIDIA pode investigar o a saida de nvidia-smi, na pior das hipóteses configurar G_MESSAGES_DEBUG para tornar observar o GNOME mais a fundo, etc.

No journalctl nao aparece nada no tempo que congela, teria outro comando?

Os recursos não estão sendo esgotados, é um problema bem pontual que ocorre na situacao que mencionei.

Não investigue só antes, ou na hora, de uma investigada também no tempo após, de uma investigada nas mensagens de kernel também (dmesg)

Você tem certeza? Travamentos silenciosos sem log do ocorrido costumam ser problemas de recursos. Quando se trata de bugs, problemas e defeitos, é melhor ser saudavelmente cético e buscar a prova cabal, pode ser um estouro de memória muito momentâneo.

De resto, não tem muito mais o que fazer se não vasculhar o culpado, tentar encontrar uma forma de “remendar”, desativar ou trocar, e se possível reportar.

Só aparece que fechei o navegador e que o processo xwayland foi morto pelo usuario (alt + print + f para destravar o sistema).

Pode ser… se só vejo alguns poucos minutos de video, o sistema congela e descongela logo apos e o cpu vai em 100, porem ram nao muda (ou sera que muda mais rapido que o htop consegue atualizar?).

Depende da pressão do seu sistema, se você tem folga ou não para demorar a estourar o limite de memória.

Também depende de como você observa, não é uma boa ideia observar de dentro da própria DE. Nestes casos o melhor é por algo para gravar periodicamente em um arquivo, de um TTY, também pode ser interessante procurar por warning, fail, não só error, monitorar a memória da GPU, verificar quais foram os processos ofensivos via top, etc.

Existem muitas possibilidades para explorar quem é o culpado, mas é um processo investigativo.

Infelizmente o melhor que podemos fazer aqui é te dar ideias do que investigar, hipóteses de onde procurar por uma causa.

Outra questão é que, pode ser alguma modificação que você fez (se você fez alguma), diversas coisas como ajustes na pressão de memória, regras de alocação, etc, podem resultar em problemas.

Pode inclusive ser um estouro de cache, algum engasgo de IO (pressão na memória de paginação, não na RAM de fato), enfim, existem muitas possibilidades.

1 curtida


O ssh funciona mesmo com o sistema travado, então é só a GUI mesmo.
Tirei essa print com ssh num outro pc, dá pra ver que o Xwayland ta usando 100% de cpu enquanto o gnome ta travado, alguma ideia?

Na verdade ele não congela para sempre, quanto mais vídeos rodo no navegador, por mais tempo é travado, mas eventualmente ele volta.

Descobri uma coisa:
O sistema só trava se o chromium estiver com a flag VaapiVideoDecodeLinuxGL, mas não queria ficar sem ela. A pergunta maior é porque e como uma flag no navegador consegue travar o gnome.

VA-API envolve a GPU na tarefa de decodificar o vídeo. Se o driver de vídeo tiver algum bug envolvendo VA-API ou o Chrome fizer mal uso da API, o que ainda hoje é comum dependendo da GPU, isso vai corromper a GPU.

A GPU é capaz de se recuperar, mas perde todo o contexto (framebuffers, etc) no processo. Dependendo da GPU, hoje em dia o GNOME não é capaz de se recuperar.

Estranho que não apareceu nada no dmesg ou journalctl, erros envolvendo VA-API costumam aparecer.

O erro ocorre quando fecho o navegador. Se congelar → descongelar → abrir o navegador novamente → tentar reproduzir um vídeo, o vídeo fica com delay de alguns segundos. Explicando melhor: o vídeo começa a rodar, a imagem trava e fica com simbolo de loading mas o audio continua e logo após a imagem sai do loading e fica desincronizado.
Não aparece nenhum erro no navegador se aberto pelo terminal.
Bem estranho.

Acho que entendi melhor, neste caso o Chrome “domina a GPU” de alguma forma, mas não chega a provocar o corrompimento de memória ou um travamento total.

Ai é silencioso mesmo, só monitorando o uso da GPU ( nvidia-smi, intel_gpu_top, radeontop), e neste caso apenas numa NVIDIA ficaria claro quem é o culpado, já que reporta o uso por processo. Ou percebendo que é o Chrome ao usar VA-API, como você fez, explorando.

Infelizmente não existe uma forma de controlar quanta memória e tempo de GPU um processo pode usar ao nível do OS. GPUs não tem schedulers no mesmo sentido que CPUs. Às vezes nice/renice conseguem ajudar por indiretamente controlar o acesso a GPU, mas acho que não é o caso aqui.

Você pode desativar e reportar/pesquisar, especificamente envolvendo o seu hardware, pode ser que haja algo no bug tracker do Chrome.

1 curtida

Pode e tá rolando um vazamento de memória do processe de GPU do Chrome. Tá com mt cara de ser isso.

Pode, mas continua sendo o mesmo problema, a mesma forma de detectar e a mesma forma de remendar. GPUs não tem schedulers nem um sistema de gestão de memória, no mesmo sentido que o OS.