Recentemente atualizei meu desktop para a versão 13.2 do Debian, e desde então o sistema tem crashado com uma frequência absurda, algo que nunca ocorreu antes.
Já tive problemas com crashes antes, mas eram muito raros, independente do quão pesada fosse a tarefa que eu estivesse executando. Agora, o sistema congela independente do que eu estiver fazendo, seja jogar, assistir vídeos ou até mesmo lendo um PDF.
Meu notebook também está na mesma versão do sistema, mas nunca tenho nenhum tipo de problema com ele. Estou começando a pensar que pode ser algum problema de hardware, mas acho difícil considerando que esses problemas constantes começaram após ter atualizado.
Há algum arquivo que crie logs quando o sistema congela e preciso forçar a reinicialização para eu poder conferir? Ou alguém tem alguma sugestão do que pode ajudar?
De quebra, aproveito para comentar que meu Firefox também crasha as páginas com uma frequência absurda depois de um tempo de uso. Parece que quanto mais tempo passo com o navegador aberto, mais ele começa a crashar as abas abertas, e vez ou outra o aplicativo em si. Por acaso passar a usar alguma versão ESR pode dar menos dor de cabeça? Pois algumas vezes a página nem sequer carrega e a aba já crasha, principalmente em apps do Google Workspace, é bizarro.
Acredito estar enfrentando o mesmo problema e estou buscando algum fio de esperança. Tenho um notebook Dell G15 5530 com as seguintes especificações:
Intel i5 13ª geração
NVIDIA RTX 3050 6 GB
24 GB de RAM
Dual boot com Windows + Debian 13.2
No Windows tudo funciona perfeitamente, sem travamentos.
Criei uma partição separada para testar o Debian 13 antes de migrar definitivamente, e segui meu próprio guia de instalação
O sistema começa a congelar frequentemente
Os travamentos acontecem tanto usando a interface gráfica quanto acessando via SSH. Em alguns casos, preciso reiniciar o notebook até duas vezes para voltar ao normal.
1° su
2° visudo - Adicione a linha abaixo da do root
‘user’ ALL=(ALL:ALL) ALL
3° apt install sudo vim network-manager
4° sudo vim /etc/apt/sources.list - adicione contrib non-free ao final de cada URL
5° sudo vim /etc/network/interfaces - adicione a linha abaixo “#” as linhas abaixo de “# The Primary network interface”
6° sudo vim /etc/NetworkManager/NetworkManager.conf - troque o parametro correspondente pelo parametro abaixo
[ifupdown]
managed=true
7° sudo systemctl restart NetworkManager wpa_supplicant
8° sudo apt install systemd-timesyncd
9° vim /etc/systemd/timesyncd.conf - adicione a linha abaixo
Validei aqui e ele por padrao já vem habilitado na inicialização .
Senti que o travamento ocorre a partir do momento que instalo o pacote nvidia-driver do repositorio debian, então quando muda o driver do nouveau (Apesar de nao ter utilizado muito ele com nouveau) para o nvidia começa a apresentar mais esses congelamentos, não sei se é algo apenas da minha máquina, mas consegui capturar alguns logs:
############################ LOGS #############################
nov 27 21:39:09 dell-G15 kernel: watchdog: BUG: soft lockup - CPU#6 stuck for 23s! \[gnome-shell:2002\]
nov 27 21:39:17 dell-G15 kernel: watchdog: BUG: soft lockup - CPU#13 stuck for 22s! \[pool-45:4439\]
nov 27 21:39:37 dell-G15 kernel: watchdog: BUG: soft lockup - CPU#6 stuck for 49s! \[gnome-shell:2002\]
nov 27 20:46:09 dell-G15 kernel: watchdog: Watchdog detected hard LOCKUP on cpu 10
nov 27 20:46:09 dell-G15 kernel: watchdog: Watchdog detected hard LOCKUP on cpu 3
nov 27 20:46:09 dell-G15 kernel: watchdog: Watchdog detected hard LOCKUP on cpu 6
nov 27 20:46:09 dell-G15 kernel: watchdog: Watchdog detected hard LOCKUP on cpu 4
nov 27 21:47:20 gnome-keyring-secrets.desktop\[1998\]: discover_other_daemon: 1 GNOME_KEYRING_CONTROL=/run/user//keyring
nov 27 21:47:20 gnome-keyring-daemon\[1998\]: discover_other_daemon: 1
nov 27 21:47:20 gnome-keyring-daemon\[1798\]: The PKCS#11 component was already initialized
nov 27 21:47:20 gnome-keyring-d\[1798\]: The PKCS#11 component was already initialized
nov 27 21:47:20 gnome-keyring-daemon\[1999\]: discover_other_daemon: 1
nov 27 21:47:20 gnome-keyring-pkcs11.desktop\[1999\]: discover_other_daemon: 1 GNOME_KEYRING_CONTROL=/run/user//keyring
nov 27 21:47:20 systemd\[1769\]: app-gnome-gnome\\x2dkeyring\\x2dpkcs11-1989.scope: PID 1989 vanished before we could move it to target cgroup ‘/user.slice/user-.slice/user@.service/app.slice/app-g…’
nov 27 21:47:20 systemd\[1769\]: app-gnome-gnome\\x2dkeyring\\x2dpkcs11-1989.scope: No PIDs left to attach to the scope’s control group, refusing.
nov 27 21:47:20 systemd\[1769\]: app-gnome-gnome\\x2dkeyring\\x2dpkcs11-1989.scope: Failed with result ‘resources’.
nov 27 21:47:20 systemd\[1769\]: Failed to start app-gnome-gnome\\x2dkeyring\\x2dpkcs11-1989.scope - Application launched by gnome-session-binary.
nov 27 21:47:20 systemd\[1769\]: app-gnome-gnome\\x2dkeyring\\x2dsecrets-1988.scope: PID 1988 vanished before we could move it to target cgroup ‘/user.slice/user-.slice/user@.service/app.slice/app-…’
nov 27 21:47:20 systemd\[1769\]: app-gnome-gnome\\x2dkeyring\\x2dsecrets-1988.scope: No PIDs left to attach to the scope’s control group, refusing.
nov 27 21:47:20 systemd\[1769\]: app-gnome-gnome\\x2dkeyring\\x2dsecrets-1988.scope: Failed with result ‘resources’.
nov 27 21:47:20 systemd\[1769\]: Failed to start app-gnome-gnome\\x2dkeyring\\x2dsecrets-1988.scope - Application launched by gnome-session-binary.
nov 27 21:47:20 gnome-shell\[2008\]: Running GNOME Shell (using mutter 48.4) as a X11 window and compositing manager
nov 27 21:47:20 gnome-shell\[2008\]: Enabling experimental feature ‘scale-monitor-framebuffer’
nov 27 21:47:20 gnome-shell\[2008\]: Enabling experimental feature ‘xwayland-native-scaling’
nov 27 21:47:20 /usr/libexec/gdm-x-session\[1835\]: (II) modeset(0): EDID vendor “CMN”, prod id 5410
nov 27 21:47:20 /usr/libexec/gdm-x-session\[1835\]: (II) modeset(0): Using EDID range info for horizontal sync
nov 27 21:47:20 /usr/libexec/gdm-x-session\[1835\]: (II) modeset(0): Using EDID range info for vertical refresh
nov 27 21:47:20 /usr/libexec/gdm-x-session\[1835\]: (II) modeset(0): Printing DDC gathered Modelines:
nov 27 21:47:20 /usr/libexec/gdm-x-session\[1835\]: (II) modeset(0): Modeline "1920x1080"x0.0 285.08 1920 1968 2000 2080 1080 1090 1095 1142 +hsync -vsync (137.1 kHz eP)
nov 27 21:47:20 /usr/libexec/gdm-x-session\[1835\]: (II) modeset(0): EDID vendor “CMN”, prod id 5410
nov 27 21:47:20 /usr/libexec/gdm-x-session\[1835\]: (II) modeset(0): Using hsync ranges from config file
nov 27 21:47:20 /usr/libexec/gdm-x-session\[1835\]: (II) modeset(0): Using vrefresh ranges from config file
nov 27 21:47:20 /usr/libexec/gdm-x-session\[1835\]: (II) modeset(0): Printing DDC gathered Modelines:
nov 27 21:47:20 /usr/libexec/gdm-x-session\[1835\]: (II) modeset(0): Modeline "1920x1080"x0.0 285.08 1920 1968 2000 2080 1080 1090 1095 1142 +hsync -vsync (137.1 kHz eP)
nov 27 21:47:20 /usr/libexec/gdm-x-session\[1835\]: (–) NVIDIA(GPU-0): DFP-0: disconnected
nov 27 21:47:20 /usr/libexec/gdm-x-session\[1835\]: (–) NVIDIA(GPU-0): DFP-0: Internal TMDS
nov 27 21:47:20 /usr/libexec/gdm-x-session\[1835\]: (–) NVIDIA(GPU-0): DFP-0: 165.0 MHz maximum pixel clock
nov 27 21:47:20 /usr/libexec/gdm-x-session\[1835\]: (–) NVIDIA(GPU-0):
nov 27 21:47:21 systemd\[1769\]: Started org.gnome.SettingsDaemon.ScreensaverProxy.service - GNOME FreeDesktop screensaver service.
nov 27 21:47:21 systemd\[1769\]: Started org.gnome.SettingsDaemon.Rfkill.service - GNOME RFKill support service.
nov 27 21:47:21 kernel: rfkill: input handler disabled
nov 27 21:47:21 systemd\[1769\]: Started app-gnome-org.gnome.Evolution\\x2dalarm\\x2dnotify-2142.scope - Application launched by gnome-session-binary.
nov 27 21:47:21 systemd\[1769\]: Started app-gnome-org.gnome.SettingsDaemon.DiskUtilityNotify-2169.scope - Application launched by gnome-session-binary.
nov 27 21:47:21 systemd\[1769\]: Started app-gnome-org.gnome.Software-2164.scope - Application launched by gnome-session-binary.
nov 27 21:47:21 systemd\[1769\]: app-gnome-user\\x2ddirs\\x2dupdate\\x2dgtk-2154.scope: PID 2154 vanished before we could move it to target cgroup ‘/user.slice/user-.slice/user@.service/app.slice/app-…’
nov 27 21:47:21 systemd\[1769\]: app-gnome-user\\x2ddirs\\x2dupdate\\x2dgtk-2154.scope: No PIDs left to attach to the scope’s control group, refusing.
nov 27 21:47:21 systemd\[1769\]: app-gnome-user\\x2ddirs\\x2dupdate\\x2dgtk-2154.scope: Failed with result ‘resources’.
nov 27 21:47:21 systemd\[1769\]: Failed to start app-gnome-user\\x2ddirs\\x2dupdate\\x2dgtk-2154.scope - Application launched by gnome-session-binary.
The use of the GSP firmware, enabled by default since version 555 of the NVIDIA driver released in June 2024, is known to cause a range of issues including Vulkan failures and system crashes.
To disable it, use the NVreg_EnableGpuFirmware=0module parameter for the nvidia kernel module. This only works with the proprietary NVIDIA driver: see NVIDIA#Installation if switching from the open source driver.
Do not forget to regenerate the initramfs if needed. To have this new kernel module option take effect, reboot.
If Xorg outputs an error about "conflicting memory type" or "failed to allocate primary buffer: out of memory", or crashes with a “Signal 11” while using nvidia-96xx drivers, add nopat to your kernel parameters.
If the NVIDIA compiler complains about different versions of GCC between the current one and the one used for compiling the kernel, add in /etc/profile:
Testei a desativar o GSP Firmware e o RenderAccel, segui o método de imitação conforme documentação do Debian e independente se for Wayland ou Xorg o sistema continua congelando aleatoriamente.
Nas diversas reinstalações que fui realizando realmente pude ter 99% das vezes que o sistema congelava era após instalar o driver nvidia.
Não sei se seria por ser uma dual GPU em minha máquina, porem sem ser o driver proprietário funciona até que muito bem no tempo que fico configurando antes de instalar o nvidia-drive, não percebi nenhum problema até essa parte.
Agradeço essas dicas – que já anotei, para experimentar em casos semelhantes:
Também tenho experimentado alguns congelamentos (freeze) – e às vezes isso parece relacionado com algum crash do Kwin / KDE Plasma – principalmente no Arch Linux, que uso 99% do tempo… mas já vi acontecer em alguma outra distro, que uso menos (tenho várias, em multiboot).
No meu caso, acontece poucas vezes. – Às vezes acontece quando o Arch já está há vários dias sem reiniciar.
Isso já acontece há vários anos – Pelas minhas anotações, desde 2020, quando montei meu PC atual (i5 9400, com 16 GB RAM; e iGPU Intel, onboard) – mas tornou-se mais frequente, de uns 2 anos para cá… ou fui eu que passei a anotar mais?
Não lembro de muitos casos assim no meu velho PC (2 x Core2 Duo, com 4 GB RAM; e iGPU Intel, onboard), que usei de 2009 até 2020 – mas pode ser que eu não tivesse anotado, porque era muito mais comum, apenas ficar lento demais, devagar quase travando?
Existem tantas causas possíveis e imagináveis – e acontece tão poucas vezes – que até agora, fico mais observando, do que tendo pressa em mexer.
No começo, achei que pudesse ter alguma coisa a ver com o VLC – que eu deixava ligado direto, tocando aleatoriamente 5.000 músicas. – Parei de usar o VLC, e os casos diminuíram bastante.
Eu deixava o Google Earth aberto direto. – Agora, abro só quando preciso, e fecho de novo. – Tenho a impressão de que também diminuiu, depois disso.
Agora, resta o Google Chrome, que fica aberto a semana inteira. – Evito deixar muitas abas abertas. – Mesmo assim, o uso de Memória RAM vai aumentando, dia após dia… e não sei se tem alguma coisa a ver com isso.
Esta semana, vi por aqui alguma coisa sobre Swappiness, fui pesquisar mais, e resolvi iniciar uma experiência de longo prazo: – Em geral, as distros vêm configuradas com Swappiness=60 e Cache-Pressure=100.
Swappiness determina se o Swap vai ser usado “logo”, ou só em último caso, por exemplo. – Mudei de 60 para 10 (no Arch Linux), para que seja usado só em último caso.
Durante 4 ou 5 anos, só vi Swap ser usado 1 única vez – e me baseio em milhares de Capturas de Tela, que faço o tempo todo, para registrar atualizações do sistema, limpeza de pacotes, previsões de tempo, enfim, qualquer coisa que me chame atenção. – Só nos últimos meses, tenho percebido algum uso de Swap, mas sempre muito pouco.
Tenho 16 GB RAM, e uma partição Swap de 11 GB – que raramente vejo sair do zero, como já disse. – Mesmo assim, é uma operação de “leitura / escrita” em um SSD que já está com mais de 5 anos de uso, e prefiro reduzir as chances de alguma falha.
Quando ao “Cache-Pressure”, 100 significa que o cache de dados na RAM pode desbancar o cache de código (aplicativos). – Por exemplo, o Dolphin, após dias e dias navegando em várias pastas com milhares de arquivos, pode acontecer de o cache desses dados competir e levar ao apagamento do cache do código do Dolphin. – Neste caso, ao abrir ou restaurar o Dolphin (minimizado), haveria demora em exibi-lo, porque o código teria de ser lido de novo em SSD. – Li alguém dizer que prefere ver o Dolphin reabrir / restaurar rapidamente; e tudo bem, esperar que depois ele recarregue os dados sobre os arquivos de uma pasta.
Estou falando abobrinha, claro. – Não entendo xongas desses bits & bytes. – Mas resolvi experimentar por um longo tempo, para ver se faz alguma diferença:
Vou ficar nisso algumas semanas, para ver se tem algum efeito que se possa perceber – e no futuro, experimentar zRAM – em vez do Swap no SSD.
Talvez zRAM seja mais efetivo – se é que tudo isso tem alguma coisa a ver com os raros congelamentos e crashes – mas prefiro experimentar 1 coisa de cada vez, para não misturar as coisas e ficar sem saber qual delas fez algum efeito (ou não).
Uma coisa que observei, é que quase todas as distros vêm com Swappiness=60 e Cache-Pressure=100. – Das que eu uso, só o PCLinuxOS e o MX Linux vieram com valores diferentes:
Eu estava lendo sobre isso esses dias… das distros não serem totalmente otimizadas por questão de compatibilidade com diversas configurações de hardware, a maioria nivela por baixo. Principalmente em relação ao uso de memória. Bom que vc está nessa trilha aproveite e olhe TB sobre a paginação de memória e também sobre Linux governor CPU relativo as configurações que gerenciam o consumo de energia da cpu.
Nesses testes que realizei eu estava reinstalando o Debian e testando soluções diferentes até ir (que não foi até o momento), mas valeu pela dica.
Estranho, que testei o pop_os com a distro para placas nvidias e nao tive nenhum problema. Usando ele por uns 30 minutos que normalmente ja tempo para os congelamentos acontecerem.
As versões do pop_os que testei foi 22.04 e a 24.04 no Gnome em Wayland e Xorg.
Nas poucas leituras que fiz sobre Swappiness, vi uma explicação razoável: – O Debian viria assim (60 e 100), por ser a melhor configuração para servidores. – Será verdade? Faz sentido? Não sei.
Mas o Arch não “vem”. – O usuário é que “constrói” sua distro – e foi isso que eu fiz, na base do RTFM (não usei nem o tal script de instalação facilitada).
Só posso concluir que os pacotes upstream já venham com essas configurações por padrão – pois o Arch não costuma alterar nada. – Apenas oferece os pacotes recebidos upstream.
Eu usei os scripts que já tenho agendados para rodar aos 5 minutos e aos 6 minutos após o boot, em todas as distros. – No Domingo, carreguei todas elas, para fazer a atualização semanal – e depois carreguei de novo, uma por uma, para registrar as informações das distros atualizadas.
Os arquivos-texto com essas informações vão para uma pasta única – onde eu executo um script Summary.sh que extrai os dados de todos os arquivos, em sequências organizadas:
Por fim, é só usar o recurso de “seleção de blocos” do KWrite / Kate, para emparelhar os nomes das distros ao lado de cada sequência de dados – desde que os totais (indicados embaixo) tenham a mesma quantidade:
Muito bom! – Com o tempo, espero experimentar novas modificações, como essas.
Por enquanto, não me sinto capaz de recomendar nada. – Estou só começando a fazer essas experiências, e ainda nem sei se vão dar algum resultado positivo.
Com relação aos “meus” casos de congelamento, a única certeza que tenho, é que costumam ser deslanchados quando abro algumas layers – em especial, no Chrome, que uso o tempo todo – e mais especificamente, layers do Facebook:
Quando a camada aparece em preto sólido, já sei que vem problema pela frente. – Tento fechar aquela aba (CTRL+W), tento fechar o próprio Chrome, e se possível também os demais aplicativos, e reinicio. – Se eu fizer isso logo ao perceber os primeiros sintomas, em geral não chega a congelar.
Depois de reiniciar, vivo feliz por mais 4 ou 5 dias.
É cada vez mais raro, eu deixar o problema atingir o congelamento total – e ter de reiniciar na marra. – Mesmo assim, optei por converter a /home do Arch para XFS – pois os desligamentos forçados acabam acumulando algum problema em sistema de arquivo ext4.
(Estou chutando um pouco, é claro. Não posso afirmar com certeza, porque não tenho conhecimentos suficientes para garantir).
Esses scripts estão aqui – embora não totalmente atualizados, pois estou sempre adicionando mais alguma coisa – como ocorreu agora, para monitorar Swappiness e Cache-Pressure.
Cara, usei o Debian por um bom tempo. Antes eu ficava alternando bastante entre distros, mas depois do 11 eu sosseguei. Migrei para o 12 e depois para o 13 sem nem pensar em usar outra distro. Na minha máquina anterior eu usava um i5 de 6ª geração, uma wireless “xing-ling” USB e uma GT1030 2GB — e sempre tive melhor performance instalando o driver que se baixa direto no site da NVIDIA, aquele que roda como um script.
Agora estou com um Ryzen 5 5600, a wireless é PCIe e tenho uma RX 6600. Aí nem me preocupava mais com driver de vídeo. Porém, depois de tantos anos no Debian, quando migrei para o 13 fiquei com uma sensação estranha, como se algo não estivesse certo. Parecia meio “amarrado”; não sei explicar direito, mas a sensação estava lá.
Fiquei tanto tempo só usando o sistema que eu estava “destreinado” de mexer na linha de comando e totalmente por fora do systemd. Instalei a ferramenta de logs do GNOME, o gnome-logs, achei ela muito boa e me mostrou os erros de forma bem prática.
Outra coisa que fiz foi usar sudo dmesg --level=emerg,alert,crit,err. Enfim… aparecia um monte de erro. Alguns relacionados à placa wireless e outros do próprio sistema. Inclusive eu tenho anotado aqui algumas correções que eu tinha que fazer, anida tenho salvo ele aqui,acertos_debian13.txt:
1 - Corrigir mensagem de boot SGX - Erro**:** x86/cpu: SGX disabled or unsupported by BIOS
4 - Erro do ALSA - Erro**:** /usr/lib/udev/rules.d/90-alsa-restore.rules:22
GOTO=“alsa_restore_std” has no matching label, ignoring.
Correção:
sudo nano /usr/lib/udev/rules.d/90-alsa-restore.rules
Na linha 26, troque:
LABEL="alsa_restore_go" por LABEL="alsa_restore_std"
Os erros 1 e 2 eu confesso que nem sei exatamente o que eram. Fiquei naquela de pesquisar em tudo quanto é canto, fui testando várias coisas, e um dia simplesmente pararam de aparecer — mas não sei se realmente corrigi ou só joguei “panos quentes”.
Agora, os erros 3 e 4 me pareceram um pouco de desleixo da distro. Não sei se foi a correria para lançar o Debian 13 “mais atualizado” que o normal, mas mesmo depois de meses — com o erro do ALSA escancarado no GitHub — os caras não corrigiram. Isso foi me irritando.
Essa sensação de que o sistema não estava a mesma coisa foi me incomodando até eu resolver testar outras distros. Tentei o Fedora, mas sabe como é: quem está acostumado com Debian não consegue ficar muito tempo no Fedora. Até que conheci o Void. Aí foi um boom! Minha máquina virou um foguete. Usei por uns 4 meses, mas fuçando demais acabei fazendo alguma cagada e o sistema crashou, hehe! Como eu teria que reinstalar do zero, resolvi insistir no Debian mais uma vez — e aí ficou evidente aquela sensação de que o sistema está estranho, meio amarrado.
Por enquanto estou no Alpine, e a máquina está um foguete. Estou até evitando fazer muitas peripécias porque, se crashar o sistema, não sei se animo reinstalar: deu muito trabalho até deixar tudo redondinho.
Enfim, talvez essa experiência te ajude. Tenta olhar o gnome-logs e usar o dmesg; vê se ainda tem erro do PipeWire e do ALSA, e também verifica a questão de gestão de energia, wireless e Bluetooth, que eram os que davam erro aqui. Sobre instalar o driver da NVIDIA baixado direto do site, talvez também dê bons resultados.
Tinha usado meu desktop pela última vez na quinta-feira, e fui usar agora pouco e o desespero bateu, pois o sistema simplesmente não queria dar boot em nada, nem mesmo na live ISO do Dr Parted, quando tentei bootar pra usar o boot-repair.
Felizmente, o problema era mais clássico e simples do que eu esperava: a maldita da memória RAM.
Tenho 24GB de memória, sendo dois pentes de 8GB e dois de 4GB. Não sei porque o problema começou agora, depois de anos com essa configuração, mas retirei todas e fui inserindo uma a uma, então descobri que uma memória está com problema. Deixei ela de fora e tudo voltou ao normal.
De qualquer forma, muito obrigado pelas sugestões. Acabou que descobri várias coisas que podem vir a calhar no futuro.
