Guia de sobrevivência wi-fi no Linux Mint: do power save ao loop de eventos de driver

Hoje compartilho um guia definitivo sobre como lidar com instabilidades de Wi-Fi no Linux Mint, baseado em perrengues reais que passei na minha própria estação de trabalho. Quando se trabalha há anos resolvendo problemas de infraestrutura e suporte N2, entende-se que rede não é apenas "conectar ou cair" - é uma dança complexa entre hardware, driver, kernel e orquestradores de sistema.

Recentemente, enfrentei dois cenários distintos que quase derrubaram minha produtividade. O primeiro era o clássico desaparecimento da rede, e o segundo era algo muito mais sinistro: uma degradação de performance sistêmica causada por um driver em conflito.

Abaixo, desconstruo as camadas de falha e apresento as soluções forenses necessárias para manter seu sistema estável.

1. O cenário clássico: o desaparecimento da rede#

O problema era direto e irritante: do nada, a rede caía. Não era apenas Wi-Fi; a rede cabeada também ficava "indisponível", e o sistema não listava absolutamente nada até que um reboot fosse realizado.

Onde a rede morria#

Quando a rede some e um restart simples não resolve, eu desconfio da camada mais baixa. Iniciei verificando o estado físico e lógico do rádio via rfkill:

rfkill list

Se o rádio estivesse em Soft block, a solução seria imediata:

sudo rfkill unblock all

No entanto, em muitos chipsets Realtek ou Intel, o culpado é o Wi-Fi Power Save. O NetworkManager coloca a placa em economia de energia e ela falha ao tentar "acordar".

A Solução Definitiva para Power Save: Editei o arquivo /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf e mudei o valor de 3 para 2:

[connection]
wifi.powersave = 2

2. Protocolos de backup e pré-requisitos de sistema#

Antes de fazer alterações em arquivos de configuração de módulos do Kernel ou de orquestradores de rede, é de suma importância realizar backups preventivos dos arquivos envolvidos. Isso garante o restabelecimento imediato das operações no caso de erros sintáticos ou comportamentos indesejados do hardware.

Criando backups de configuração de módulos#

Execute os seguintes comandos no terminal para garantir a segurança dos arquivos antes de realizar qualquer alteração no diretório de modprobe:

# Criar backup individual do arquivo de configuração do driver Realtek
if [ -f /etc/modprobe.d/rtw88.conf ]; then
  sudo cp /etc/modprobe.d/rtw88.conf /root/rtw88.conf.bak.$(date +%Y%m%d)
  echo "Backup de rtw88.conf criado em /root/"
else
  echo "Arquivo /etc/modprobe.d/rtw88.conf não existia previamente."
fi

# Backup preventivo completo de todo o diretório /etc/modprobe.d/
sudo cp -r /etc/modprobe.d/ /root/modprobe-backup-$(date +%Y%m%d)/

# Verificar o estado atual e existência do arquivo
ls -la /etc/modprobe.d/rtw88.conf

Esses backups permitem reverter rapidamente as opções de carregamento de driver caso ocorra alguma incompatibilidade inesperada.

3. Validação detalhada do hardware e do kernel#

Antes de diagnosticar se um driver está defeituoso, é essencial realizar um levantamento de compatibilidade física, lógico-operacional do barramento, estado de firmware e versão do kernel utilizada.

A. Validação do kernel#

As otimizações de drivers Realtek são fortemente atreladas à versão do kernel ativa. O suporte ao rtw88_8822ce foi severamente modificado nas ramificações mais recentes do kernel LTS.

# Verificar a versão ativa do Kernel do Linux
uname -r

# Testar em modo simulação se o módulo está compilado e disponível para o kernel atual
modprobe -n -v rtw88_8822ce 2>&1

# Verificar se há atualizações de pacotes do kernel pendentes no repositório
apt list --upgradable | grep linux-image

# Listar arquivos físicos do driver rtw88 para o kernel atual
ls /lib/modules/$(uname -r)/kernel/drivers/net/wireless/realtek/rtw88/

B. Validação do hardware#

Tudo começa na comunicação física com o barramento PCI Express. Se a placa Wi-Fi sumir eletricamente do barramento, nenhuma alteração de driver resolverá.

# Localizar adaptador Wi-Fi no barramento PCI
lspci | grep -i -E "network|wireless"

# Consultar status físico e lógico do rádio (rfkill)
rfkill list all

# Verificar se a interface wlp3s0 está configurada no sistema (UP ou DOWN)
ip link show wlp3s0

# Auditar mensagens de erro de hardware ou falha de inicialização no dmesg
dmesg | grep -i "error\|fail" | grep -i "wifi\|wireless\|wlp3s0"

C. Validação de firmware#

Mesmo com o driver carregado, a placa requer blobs de firmware proprietários fornecidos pelo pacote firmware-realtek. Se o firmware falhar ao carregar, a interface de rede falhará ao subir.

# Verificar o carregamento do firmware da placa Wi-Fi no dmesg
dmesg | grep -i firmware | grep -i rtw88

# Validar o pacote de firmware Realtek instalado no Linux Mint
dpkg -l | grep firmware | grep -i realtek

# Verificar se há novas versões de firmware disponíveis para atualização
apt list --upgradable | grep firmware

4. Diagnóstico de driver e pilha de rede#

Quando o hardware está visível e o kernel é compatível, o problema reside na comunicação entre as camadas lógicas: Hardware ➔ Driver ➔ wpa_supplicant ➔ NetworkManager ➔ D-Bus / Interface Gráfica.

Hardware RTL8822CE ──Interrupts/IRQs──▶ Módulo Kernel rtw88_8822ce
                                          │
                                          ▼ nl80211
                                     wpa_supplicant
                                          │
                                          ▼ D-Bus IPC
                                     NetworkManager
                                          │
                                          ▼ Configurador
                                     Interface do Usuário / SysTray

A. Status de carregamento do driver#

Verifique se os módulos do Kernel estão ativos e respondendo na memória volátil:

# Verificar se o módulo rtw88 está ativo e carregado na memória do kernel
lsmod | grep rtw88

# Validar módulos de suporte e sub-sistemas de rede wireless ativos
lsmod | grep -E "rtw88|wlan|cfg80211|mac80211"

# Inspecionar parâmetros disponíveis expostos pelo driver rtw88_8822ce
modinfo rtw88_8822ce | grep -i "parm"

# Auditar dmesg em tempo real buscando por falhas ou timeouts do driver
dmesg | grep -i "rtw88\|wlp3s0" | tail -20

B. Saúde e configuração do networkmanager#

O NetworkManager orquestra os dispositivos de rede baseando-se em arquivos de regras declarativas. Um bug ou loop no NetworkManager pode desconectar a placa repetidamente.

# Verificar o status ativo do serviço orquestrador de rede
systemctl status NetworkManager

# Checar status geral do NetworkManager (conectividade, estado)
nmcli general status

# Verificar o status das interfaces de rede conhecidas
nmcli device status

# Listar conexões ativas registradas
nmcli connection show

# Confirmar se a interface wlp3s0 está de fato no modo "managed" pelo NM
nmcli device status | grep wlp3s0

C. Validação do wpa_supplicant#

O wpa_supplicant é responsável pela criptografia e handshakes Wi-Fi (WPA/WPA2/WPA3). Travamentos nesse daemon causam quedas constantes e loops de autenticação.

# Verificar o status de execução do daemon de autenticação WPA/WPA2
systemctl status wpa_supplicant

# Inspecionar as definições padrão de conexões wpa_supplicant
cat /etc/wpa_supplicant/wpa_supplicant.conf

# Auditar logs recentes do serviço para identificar problemas de autenticação
journalctl -u wpa_supplicant --since "10 minutes ago"

# Buscar padrões de erro específicos nos logs históricos
journalctl -u wpa_supplicant | grep -i -E "fail|error|reject"

D. Saúde do subsistema de comunicação d-bus#

Os daemons NetworkManager e wpa_supplicant utilizam mensagens IPC através do D-Bus. Se o D-Bus for saturado, a interface gráfica inteira começará a responder com lag e quedas de chamadas API.

# Confirmar status operacional do dbus
systemctl status dbus

# Ler logs recentes de comunicação do subsistema D-Bus
journalctl -u dbus --since "10 minutes ago"

# Listar processos com consumo excessivo de conexões ou CPU no D-Bus
ps aux | grep dbus | sort -k3 -rn | head -5

# Verificar se o wpa_supplicant está operando normalmente com o barramento do NetworkManager
busctl tree org.freedesktop.NetworkManager 2>/dev/null | head -10

5. O cenário forense: o loop de eventos e a tempestade de interrupções#

Recentemente, o nível de dificuldade subiu. O sistema (Linux Mint, Kernel 6.8.0-106-generic) apresentava um lag de interface insuportável. O uso de CPU escalava para 95% e o Load Average batia 7.55. O mouse "pulava", e a renderização sofria atrasos visíveis.

O comportamento do kernel#

Ao rodar journalctl -f, identifiquei um flood originado no wpa_supplicant. A interface wlp3s0 (Realtek RTL8822CE) estava gerando eventos de mudança de sinal a cada 100ms.

O log era persistente: wlp3s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-72 noise=9999 txrate=58500

O valor de noise=9999 é o sentinela padrão do wpa_supplicant quando o driver não reporta o piso de ruído — o que é esperado e inofensivo por si só. O problema real era o flood: eventos SIGNAL-CHANGE disparados a cada ~100ms geravam uma tempestade de eventos (event storm) que, combinada à tentativa contínua de compensação do driver rtw88_8822ce, provocava picos extremos de interrupções de hardware (IRQs) na placa Wi-Fi. Através do comando watch -n1 "cat /proc/interrupts", vi o contador de IRQs subindo freneticamente, elevando o I/O Wait e saturando o systemd-journald em disco.

Rastreabilidade de driver#

A falha reside no driver rtw88 (especificamente no módulo rtw88_8822ce), na lógica de LPS (Leisure Power Save) e no Antenna Diversity. O driver tentava alternar entre as antenas físicas para compensar o ruído falso, disparando um callback no wpa_supplicant via nl80211. Esse loop saturava o dbus-daemon, quebrando outros serviços de interface.

Silenciando o overhead#

1. Parâmetros de Módulo (Persistence): Forcei a desativação do gerenciamento de energia profundo e travei a seleção de antena no arquivo /etc/modprobe.d/rtw88.conf:

options rtw88_core disable_lps_deep=y
options rtw88_8822ce disable_lps_deep=y ant_sel=1

1. Redução de Verbosidade via Drop-in Override do Systemd: Em vez de editar diretamente a unit em /usr/lib/systemd/system/ (que seria sobrescrita na próxima atualização do pacote), criei um drop-in override persistente para redirecionar o log para um arquivo isolado (como /var/log/wpa_supplicant.log) e ativei a flag -q (quiet):

   # Criar o diretório de drop-in override do serviço
   sudo mkdir -p /etc/systemd/system/wpa_supplicant.service.d

   # Criar o arquivo de override (ExecStart= vazio primeiro é obrigatório para limpar o padrão)
   sudo tee /etc/systemd/system/wpa_supplicant.service.d/override.conf << 'EOF'
   [Service]
   ExecStart=
   ExecStart=/usr/sbin/wpa_supplicant -u -s -O "DIR=/run/wpa_supplicant GROUP=netdev" -f /var/log/wpa_supplicant.log -t -q
   EOF

   # Recarregar as unidades e reiniciar o serviço
   sudo systemctl daemon-reload
   sudo systemctl restart wpa_supplicant

1. Limpeza de Race Condition: Matei o processo crashpad_handler (PID 8100) que havia entrado em condição de corrida devido aos micro-travamentos, liberando 23% de CPU instantaneamente.

Resultado final: O Load Average caiu de 7.55 para 0.58. Sistema fluido e estável.

6. Auditoria forense de interrupções e validação pós-fix#

Após a aplicação dos fixes descritos nas seções anteriores, é obrigatório auditar se a tempestade de interrupções (Interrupt Storm) cessou e se os novos parâmetros foram aplicados de forma persistente no Kernel.

A. Monitoramento das interrupções de hardware (irqs)#

Para verificar se as interrupções de hardware estabilizaram e se a placa parou de floodar o kernel, execute as auditorias abaixo:

# Verificar as interrupções de hardware registradas para a interface
cat /proc/interrupts | grep -i wlp3s0

# Monitorar variações de interrupções em tempo real (observe se o valor aumenta bruscamente)
watch -n1 "cat /proc/interrupts | grep -i wlp3s0"

# Executar loop de teste rápido para registrar taxa de subida de IRQs por segundo
for i in 1 2 3; do
    cat /proc/interrupts | grep wlp3s0 | awk '{print $2}'
    sleep 1
done

# Verificar se há gargalos no uso do CPU devido a I/O (I/O wait)
iostat -x 1 5

B. Validação da persistência dos parâmetros pós-recarregamento#

Não basta reiniciar o computador. É preciso auditar se os parâmetros de módulo customizados foram interpretados corretamente pelo kernel em runtime.

# Confirmar que o driver foi recarregado corretamente na memória
lsmod | grep rtw88

# Validar se os parâmetros passados em /etc/modprobe.d foram lidos com sucesso
cat /sys/module/rtw88_core/parameters/disable_lps_deep
cat /sys/module/rtw88_8822ce/parameters/ant_sel

# Testar conectividade de rede básica
ping -c 5 8.8.8.8

# Validar se a carga média do sistema (Load Average) normalizou
uptime

Se disable_lps_deep retornar Y (ou 1) e ant_sel retornar 1 (ou o valor travado), e as interrupções pararem de subir bruscamente durante o tráfego, o bug de loop de eventos foi corrigido com sucesso.

7. Tabela operacional de recuperação (no-reboot protocol)#

Se o Wi-Fi cair ou o sistema começar a travar, siga este fluxo antes de pensar em reiniciar:

8. Checklist de troubleshooting wi-fi (Linux Mint)#

Utilize o checklist operacional abaixo para triagem e correção de anomalias de conexões sem fio:

1. Diagnóstico inicial#

• [ ] Executar rfkill list para auditar possíveis bloqueios de hardware/software no rádio.
• [ ] Verificar se a interface física está presente e ativa através do comando ip link show.
• [ ] Confirmar integridade do serviço orquestrador: systemctl status NetworkManager.
• [ ] Iniciar escuta dos logs do sistema em background com journalctl -f ou tail -f /var/log/syslog.

2. Tratamento de power save (economia de energia)#

• [ ] Verificar arquivo /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf.
• [ ] Mudar valor configurado de 3 (habilitado) para 2 (desabilitado).
• [ ] Reiniciar o NetworkManager com sudo systemctl restart NetworkManager.

3. Ajuste de parâmetros do driver#

• [ ] Confirmar o módulo carregado usando o comando lsmod | grep rtw88.
• [ ] Confirmar os parâmetros reais expostos pelo driver no seu kernel antes de criar o .conf:

  modinfo rtw88_8822ce | grep -E "ant_sel|disable_lps_deep|parm"
  ls /sys/module/rtw88_core/parameters/ 2>/dev/null

• [ ] Criar o arquivo de configurações /etc/modprobe.d/rtw88.conf com as flags de desativação do LPS e seleção de antena.
• [ ] Descarregar e carregar o módulo do kernel de forma limpa:

  sudo modprobe -r rtw88_8822ce && sudo modprobe rtw88_8822ce

4. Resolução da tempestade de eventos e interrupções (event storm)#

• [ ] Monitorar a taxa de escalada de interrupções por segundo: watch -n1 "cat /proc/interrupts | grep wlp3s0".
• [ ] Criar override do systemd para o wpa_supplicant reduzindo a verbosidade (-q).
• [ ] Verificar overhead no processamento e estado de I/O Wait utilizando o comando iostat -x 1 5.
• [ ] Matar processos zumbis ou com condição de corrida que saturam a CPU (ex: crashpad_handler).

5. Validação pós-procedimento#

• [ ] Realizar teste de conectividade externo: ping -c 5 8.8.8.8.
• [ ] Auditar load average geral da máquina: uptime.
• [ ] Monitorar a estabilidade da taxa de transferência de dados e oscilações do sinal por um período de 24 horas.

9. Matriz de relação de problemas identificados#

A matriz a seguir consolida os riscos, severidades e as mitigações diretas documentadas neste guia:

Conclusão#

Neste guia documentei duas frentes: o desaparecimento clássico da rede (power save + rfkill) e o caso forense do loop de eventos no wpa_supplicant com o rtw88. Do rfkill ao barramento PCI, o diagnóstico sempre passa pelo mesmo princípio — analisar por camadas. Com os parâmetros travados no modprobe.d/, o override do systemd e a auditoria de IRQs, o sistema voltou de um Load Average de 7.55 para 0.58 sem reboot.

Veja também

Infraestrutura Anatomia de um deadlock silencioso no CloudLinux e cPanel: processos fantasmas, travas de sessão e filas TCP

Infraestrutura Do LSM ao netfilter na OCI: desmistificando selinux e liberando portas no Ubuntu minimal 24.04

Infraestrutura Sobrevivendo ao kernel panic: diagnosticando e contornando regressões no boot do CachyOS com Limine

Este post está licenciado sob CC BY-NC.