Omarchy

Omarchy/*nix notes for the USB Wi-Fi soft hang on older AMD EHCI: symptoms, dead ends, and rtw88 mitigations. The underlying issue is hardware/driver, not Omarchy-only.

Hardware context

• Older AMD AM3 board with AMD SB7x0 EHCI USB 2.0 host (example: Gigabyte GA-78LMT-S2P, Award BIOS).
• USB Wi-Fi dongle: TP-Link Archer T3U (Realtek RTL8812BU), Linux driver stack rtw88_8822bu / rtw88_usb / rtw88_core.
• Dongle on a rear USB 2.0 port (EHCI), not USB 3 / front panel if those are flaky on the chassis.
• Sole NIC was Wi-Fi in this setup (onboard Ethernet can be BIOS-disabled — worth re-enabling as a backstop).

Symptoms

• Under high sustained Wi-Fi throughput (e.g. ~650 Mbit/s on 5 GHz VHT80), the network drops.
• Dongle LED stays on (still powered).
• Machine otherwise keeps running (desktop, other services, GPU workloads continue) — not a full reboot or hard lock.
• Kernel log pattern (soft hang): rtw88 / USB: read/write register … failed with -110 (ETIMEDOUT), sometimes earlier -71 / disconnect + re-enum. Not primarily IQK-watchdog in the failure we captured.
• Contrast hard hang: LED goes dark, no VBUS — physical reseat / power-cycle only; software recover does not help.

Things tried that did not fix the soft hang

These were still useful hygiene, but high-speed soft hangs continued afterward:

1. BIOS / platform cleanup (Award-era board): ErP Support → Disabled; USB Wake Up from S3 → Disabled; prefer rear USB 2.0; keep USB Legacy Function Enabled so a USB keyboard works in Setup; M.I.T.: PCIE Clock 100 (not overclocked 103); DDR3 voltage Normal / kit-rated; NB volts Normal; BCLK Auto; modest CPU ratio OK if stable; Advanced: C1E / Cool&Quiet Disabled for sustained loads, Init Display PEG.
2. Assuming it was a full system crash — logs showed Wi-Fi/USB path only.
3. A usbcore.autosuspend=-1 line in /etc/modprobe.d/ — no-op when usbcore is built into the kernel; must be a kernel cmdline token (on Omarchy/Limine: edit /etc/kernel/cmdline then limine-update + reboot). Optional hardening only; not required for the fix that stuck.
4. Runtime recover alone (EHCI unbind/rebind + reload rtw88) — clears a soft hang after the fact, does not prevent the next load-induced wedge.

What finally worked

Persistent rtw88 module options, then reload the Wi-Fi modules (Wi-Fi drops briefly).

File: /etc/modprobe.d/rtw88-usb-mitigations.conf

options rtw88_core disable_lps_deep=1
options rtw88_usb switch_usb_mode=N

Apply / reload:

sudo tee /etc/modprobe.d/rtw88-usb-mitigations.conf <<'EOF'
options rtw88_core disable_lps_deep=1
options rtw88_usb switch_usb_mode=N
EOF

sudo modprobe -r rtw88_8822bu rtw88_usb rtw88_8822b rtw88_core
sudo modprobe rtw88_8822bu

Verify (expect Y then N):

cat /sys/module/rtw88_core/parameters/disable_lps_deep   # Y
cat /sys/module/rtw88_usb/parameters/switch_usb_mode      # N

Survives reboot. After this, the same heavy Wi-Fi load that previously soft-hung stayed rock-solid.

Recovery if soft hang recurs (LED on): unbind/rebind the EHCI host and reload rtw88 (custom usb-ehci-recover-style script). Do not treat dark-LED / no-power as the same path.

Why that fix made sense / what to watch

• Root cause model: under heavy traffic, rtw88 deep LPS (low-power sleep) on an older EHCI host left the USB command path wedged — register I/O timed out (-110) while the stick still had power (LED on).
• disable_lps_deep=1 keeps the chip out of the deepest sleep that was locking up (slightly higher idle power, more reliable under load).
• switch_usb_mode=N stops runtime USB transfer-mode switching, another stress point for Realtek USB Wi-Fi on old EHCI.
• BIOS tweaks reduce general USB flakiness but cannot stop driver deep-sleep from wedging the dongle.

Watch for recurring

• Soft (LED on) vs hard (LED dark) — different fix paths.
• After kernel / rtw88 updates, re-check the two sysfs parameters still show Y / N.
• Prefer rear USB 2.0 EHCI; keep a wired NIC enabled when possible.
• Optional: usbcore.autosuspend=-1 on the kernel cmdline if you still see USB autosuspend pain (not required for this fix).
• Don’t confuse this with GPU/VA-API video stutter (separate issue on old Polaris + no VP9/AV1 decode).

Ai disclosure: written with the help of AI (ChatGPT). You are encouraged to point out errors and omissions.