Linux Mint wi-fi survival guide: from power save to driver event loops

Linux Mint Wi-Fi Survival Guide: From Power Save to Driver Event Loops#

Hi everyone. Today I'm sharing a definitive guide on how to handle Wi-Fi instabilities on Linux Mint, based on real-world headaches I've faced on my own workstation. When you've spent years solving infrastructure problems, you understand that networking isn't just "connected or disconnected" - it's a complex dance between hardware, drivers, the kernel, and system orchestrators.

Recently, I faced two distinct scenarios that almost crippled my productivity. The first was the classic disappearance of the network, and the second was something much more sinister: systemic performance degradation caused by a conflicting driver.

Below, I deconstruct the failure layers and present the forensic solutions required to keep your system stable.

1. The classic scenario: total network disappearance#

The problem was direct and infuriating: out of nowhere, the network would drop. It wasn't just Wi-Fi; even the wired network became "unavailable," and the system wouldn't list any networks until a reboot.

Diagnosis: where the network died#

When the network vanishes and a simple restart doesn't help, I look at the lowest layer. I started by checking the radio state via rfkill:

rfkill list

If it were a Soft block, the fix would be immediate:

sudo rfkill unblock all

However, on many Realtek or Intel chipsets, the culprit is Wi-Fi Power Save. NetworkManager puts the card into a power-saving mode and it fails to "wake up" correctly.

The Permanent Power Save Fix: I edited /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf and changed the value from 3 to 2:

[connection]
wifi.powersave = 2

2. Backup protocols and system pre-requisites#

Before modifying configuration files for Kernel modules or network orchestrators, it is essential to perform preventive backups of the files involved. This ensures immediate recovery in case of syntactical errors or unexpected hardware behavior.

Creating modprobe backup files#

Run the following commands in the terminal to safeguard configurations before altering anything in the modprobe directory:

# Create individual backup of the Realtek driver configuration file
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 of rtw88.conf created under /root/"
else
  echo "The file /etc/modprobe.d/rtw88.conf did not exist previously."
fi

# Complete preventive backup of the entire /etc/modprobe.d/ directory
sudo cp -r /etc/modprobe.d/ /root/modprobe-backup-$(date +%Y%m%d)/

# Verify the current state and existence of the file
ls -la /etc/modprobe.d/rtw88.conf

These backups allow you to quickly roll back driver configurations if any unexpected incompatibility arises.

3. Detailed hardware and kernel validation#

Before diagnosing a driver as faulty, it is critical to verify hardware compatibility, PCI bus operational state, firmware loading status, and the current kernel version.

A. Kernel validation#

Optimizations for Realtek drivers are closely tied to the active kernel version. The support for rtw88_8822ce has been heavily updated in recent LTS kernel branches.

# Check the active Linux Kernel version
uname -r

# Test in simulation mode if the module is compiled and available for the current kernel
modprobe -n -v rtw88_8822ce 2>&1

# Check if there are pending kernel package updates in the repository
apt list --upgradable | grep linux-image

# List physical driver files for rtw88 on the current kernel
ls /lib/modules/$(uname -r)/kernel/drivers/net/wireless/rtw88/

B. Hardware validation#

Everything starts with physical communication over the PCI Express bus. If the Wi-Fi card disappears electrically from the bus, no driver modifications will resolve the issue.

# Locate the Wi-Fi adapter on the PCI bus
lspci | grep -i -E "network|wireless"

# Query physical and logical radio status (rfkill)
rfkill list all

# Check if the wlp3s0 interface is configured in the system (UP or DOWN)
ip link show wlp3s0

# Audit hardware errors or initialization failures in dmesg
dmesg | grep -i "error\|fail" | grep -i "wifi\|wireless\|wlp3s0"

C. Firmware validation#

Even if the driver is loaded, the card requires proprietary firmware blobs provided by the firmware-realtek package. If firmware fails to load, the network interface will fail to bring up.

# Check Wi-Fi card firmware loading in dmesg
dmesg | grep -i firmware | grep -i rtw88

# Validate the Realtek firmware package installed in Linux Mint
dpkg -l | grep firmware | grep -i realtek

# Check if new firmware versions are available for update
apt list --upgradable | grep firmware

4. Driver and network stack diagnostics#

When the hardware is visible and the kernel is compatible, the problem resides in communication between the logical layers: Driver ➔ NetworkManager ➔ wpa_supplicant ➔ D-Bus.

A. Driver loading status#

Verify if kernel modules are active and responding in volatile memory:

# Verify if the rtw88 module is active and loaded in kernel memory
lsmod | grep rtw88

# Validate active support modules and wireless network subsystems
lsmod | grep -E "rtw88|wlan|cfg80211|mac80211"

# Inspect available parameters exposed by the rtw88_8822ce driver
modinfo rtw88_8822ce | grep -i "parm"

# Audit dmesg in real-time looking for driver failures or timeouts
dmesg | grep -i "rtw88\|wlp3s0" | tail -20

B. Networkmanager health and configuration#

NetworkManager orchestrates network devices based on declarative rule files. A bug or loop in NetworkManager can repeatedly disconnect the card.

# Verify the active status of the network orchestrator service
systemctl status NetworkManager

# Check general NetworkManager status (connectivity, state)
nmcli general status

# Verify the status of known network interfaces
nmcli device status

# List registered active connections
nmcli connection show

# Confirm if the wlp3s0 interface is in "managed" mode by NM
nmcli device status | grep wlp3s0

C. Wpa_supplicant validation#

wpa_supplicant is responsible for encryption and Wi-Fi handshakes (WPA/WPA2/WPA3). Hangs in this daemon cause constant drops and authentication loops.

# Verify the execution status of the WPA/WPA2 authentication daemon
systemctl status wpa_supplicant

# Inspect default configurations for wpa_supplicant connections
cat /etc/wpa_supplicant/wpa_supplicant.conf

# Audit recent logs from the service to identify authentication issues
journalctl -u wpa_supplicant --since "10 minutes ago"

# Look for specific error patterns in historical logs
journalctl -u wpa_supplicant | grep -i -E "fail|error|reject"

D. D-bus communication subsystem health#

NetworkManager and wpa_supplicant daemons use IPC messages via D-Bus. If D-Bus is saturated, the entire UI will start responding with lag, and API calls will fail.

# Confirm the operational status of dbus
systemctl status dbus

# Read recent communication logs from the D-Bus subsystem
journalctl -u dbus --since "10 minutes ago"

# List processes consuming excessive connections or CPU on D-Bus
ps aux | grep dbus | sort -k3 -rn | head -5

# Verify if wpa_supplicant is communicating normally with the NetworkManager bus
busctl tree org.freedesktop.NetworkManager 2>/dev/null | head -10

5. The forensic scenario: event loops and interrupt storms#

Recently, the difficulty level spiked. The system (Linux Mint, Kernel 6.8.0-106-generic) exhibited unbearable interface lag. CPU usage climbed to 95%, and the Load Average hit 7.55. The mouse would "stutter," and UI rendering suffered visible delays.

Kernel behavior#

By running journalctl -f, I identified a flood originating from wpa_supplicant. The wlp3s0 interface (Realtek RTL8822CE) was generating signal change events every 100ms.

The log was persistent: wlp3s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-72 noise=9999 txrate=58500

The noise=9999 value indicated that the rtw_8822ce driver was reporting inconsistent information. This generated an Interrupt Storm. Using watch -n1 "cat /proc/interrupts", I saw the IRQ counter for the network card skyrocketing, resulting in high I/O Wait and systemd-journald saturating the disk.

Driver traceability#

The failure lies within the rtw88 driver (specifically the rtw88_8822ce module), in the LPS (Leisure Power Save) and Antenna Diversity logic. The driver tried to alternate between physical antennas to compensate for the fake noise, triggering a callback in wpa_supplicant via nl80211. This loop saturated the dbus-daemon, breaking other UI services.

Silencing the overhead#

1. Module Parameters (Persistence): I forced deep power management off and locked antenna selection in the /etc/modprobe.d/rtw88.conf file:

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

1. Verbosity Reduction: I modified the wpa_supplicant service ExecStart to redirect logs to an isolated file (like /var/log/wpa_supplicant.log) and enabled the -q (quiet) flag:

   ExecStart=/usr/sbin/wpa_supplicant -u -s -O "DIR=/run/wpa_supplicant GROUP=netdev" -f /var/log/wpa_supplicant.log -t -q

1. Race Condition Cleanup: I killed the crashpad_handler process (PID 8100) which had entered a race condition due to the micro-freezes, instantly freeing 23% of CPU.

Final Result: Load Average dropped from 7.55 to 0.58. System fluid and stable.

6. Forensic auditing of interrupts and post-fix validation#

After applying the fixes described in the previous sections, you must audit whether the Interrupt Storm has stopped and check if the new parameters have been persistently applied to the kernel.

A. Hardware interrupt monitoring (irqs)#

To verify that hardware interrupts have stabilized and the card is no longer flooding the kernel, execute the following audit commands:

# Check registered hardware interrupts for the interface
cat /proc/interrupts | grep -i wlp3s0

# Monitor live changes in interrupts (observe if the value spikes)
watch -n1 "cat /proc/interrupts | grep -i wlp3s0"

# Execute a quick loop to record the IRQ increase rate per second
for i in 1 2 3; do
    cat /proc/interrupts | grep wlp3s0 | awk '{print $2}'
    sleep 1
done

# Check for CPU bottlenecks due to I/O wait
iostat -x 1 5

B. Validation of parameter persistence after reloading#

Simply restarting is not enough. We must audit if the custom module parameters are correctly interpreted by the kernel at runtime.

# Confirm that the driver is correctly reloaded in memory
lsmod | grep rtw88

# Validate if the parameters passed to /etc/modprobe.d were loaded successfully
cat /sys/module/rtw88_core/parameters/disable_lps_deep
cat /sys/module/rtw88_8822ce/parameters/ant_sel

# Test basic network connectivity
ping -c 5 8.8.8.8

# Validate if the general system Load Average has normalized
uptime

If disable_lps_deep returns Y (or 1) and ant_sel returns 1 (or the locked value), and interrupts do not spike dramatically during traffic, the event loop bug has been successfully resolved.

7. Operational recovery toolbox (no-reboot protocol)#

If your Wi-Fi drops or the system starts freezing, follow this sequence before considering a reboot:

8. Wi-fi troubleshooting checklist (Linux Mint)#

Use the operational checklist below to screen and correct wireless connection anomalies:

1. Initial diagnosis#

• [ ] Run rfkill list to audit hardware/software blocks on the radio.
• [ ] Verify if the physical interface is present and active using ip link show.
• [ ] Confirm orchestrator service health: systemctl status NetworkManager.
• [ ] Listen to system logs in the background with journalctl -f or tail -f /var/log/syslog.

2. Handling power save#

• [ ] Check /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf.
• [ ] Change the configured value from 3 (enabled) to 2 (disabled).
• [ ] Restart NetworkManager with sudo systemctl restart NetworkManager.

3. Driver parameter adjustment#

• [ ] Confirm the loaded module using lsmod | grep rtw88.
• [ ] Map driver options by executing modinfo rtw88_8822ce.
• [ ] Create the configuration file /etc/modprobe.d/rtw88.conf with the LPS disable and antenna selection flags.
• [ ] Unload and load the kernel module cleanly:

  sudo modprobe -r rtw88_8822ce && sudo modprobe rtw88_8822ce

4. Resolving interrupt storms#

• [ ] Monitor the rate of escalating interrupts per second: watch -n1 "cat /proc/interrupts | grep wlp3s0".
• [ ] Check CPU processing overhead and I/O Wait states using iostat -x 1 5.
• [ ] Kill zombie processes or those in race conditions saturating the CPU (e.g., crashpad_handler).

5. Post-procedure validation#

• [ ] Perform external connectivity test: ping -c 5 8.8.8.8.
• [ ] Audit overall machine load average: uptime.
• [ ] Monitor transfer rate stability and signal fluctuations for a 24-hour period.

9. Identified problems and severity matrix#

The following matrix consolidates the risks, severities, and direct mitigations documented in this guide:

Production takeaways#

In Linux, networking issues are rarely binary. They require a layered analysis - from rfkill to the PCI bus, through power management. Hardware and drivers sometimes fight, but with the right infrastructure tools, you can get them talking again without needing a reboot.

See also

Infrastructure Anatomy of a silent deadlock in CloudLinux and cPanel: phantom processes, session locks, and TCP queues

Infrastructure Crontab kernel mechanics, Linux logging differences, and Exim mail spool maintenance

Infrastructure From LSM to Netfilter in OCI: Demystifying SELinux and Opening Ports on Ubuntu Minimal 24.04

This post is licensed under CC BY-NC.