## What happened

On `linux-omarchy 7.2.5-3` (kernel `7.2.5-3-omarchy`), wifi on a Qualcomm Atheros
AR9485 (`ath9k`) card suffers constant, severe packet loss (~40%+) and is
effectively unusable. The kernel log shows the driver hitting a DMA-engine
lockup and force-resetting the radio every ~8-10 seconds, continuously, for as
long as the machine is up:

```
ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006100
```

Each occurrence is followed by a full deauth/reassociate/DHCP-renew cycle
(`wpa_supplicant` logs `CTRL-EVENT-DISCONNECTED ... reason=4 locally_generated=1`
— i.e. the client's own driver/supplicant tears the link down, not the AP).
Signal quality is excellent throughout (-32 to -35 dBm), so this is not a
range/interference issue, and other devices on the same network are unaffected.

## Expected

Stable wifi with normal packet loss (well under 1%), matching behavior on the
plain `linux` kernel package on the same hardware.

## Steps to reproduce

1. Install `linux-omarchy` (currently `7.2.5-3-omarchy`) on a machine with a
   Qualcomm Atheros AR9485 (`ath9k`) wifi adapter.
2. Connect to any wifi network and leave it idle/lightly used.
3. Watch `journalctl -k -f | grep -i ath9k` — "DMA failed to stop" recurs every
   ~8-10 seconds, each one tearing down and rebuilding the wifi association.
4. `ping -c 60 -i 1 <gateway or 1.1.1.1>` shows ~40% loss.

## Isolating the cause — this is a kernel-version regression, not hardware/config

I ruled out the usual suspects before concluding this is kernel-specific:

- **Signal strength**: -32 to -35 dBm the whole time — not a range issue.
- **PCIe ASPM (software layer)**: booting with `pcie_aspm=off` on the kernel
  cmdline had zero effect — the failures continued at the identical rate.
- **PCIe ASPM (hardware register level)**: this system's ACPI FADT declares
  ASPM unsupported and withholds `_OSC` control from the OS
  (`acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS
  configuration`), so the BIOS's own ASPM setting (`ath: phy0: ASPM enabled:
  0xc42`, L1 enabled) is what's actually active in hardware regardless of the
  cmdline flag. I disabled ASPM directly via `setpci` on both the wifi
  endpoint (`04:00.0`) and its upstream root port (`00:1c.2`), confirmed via
  `lspci -vvv` that both showed `LnkCtl: ASPM Disabled`, and the DMA-stop
  resets continued at the exact same ~9s cadence with identical register
  values. This rules out PCIe power management entirely.
- **BIOS setting**: no PCIe ASPM toggle exists in this system's UEFI setup.
- **Kernel version A/B test**: both `linux` and `linux-omarchy` were installed
  side by side. Rebooting into the vanilla `linux 7.2.3-arch1-3` package (same
  hardware, same router, same everything else) produced **zero** DMA-stop
  events and **0% packet loss** over a 60-packet sustained ping test, versus
  continuous failures and ~40% loss on `linux-omarchy 7.2.5-3-omarchy`.

| | `linux-omarchy` 7.2.5-3-omarchy | `linux` 7.2.3-arch1-3 |
|---|---|---|
| DMA-stop resets | every ~9s, continuous | 0 in several minutes uptime |
| wpa_supplicant reconnects | every ~9s, continuous | 0 |
| Ping loss (60 pkts to 1.1.1.1) | ~40% | 0% |
| Beacon loss (station dump) | 653 lost / 19 rx | 0 lost / 2631 rx |

This strongly points at an `ath9k`-relevant change between the two kernel
builds/versions rather than anything in this machine's hardware or config.

## System info

- `omarchy version`: 4.0.4-1
- `omarchy version channel`: stable
- Affected kernel: `linux-omarchy 7.2.5-3` (`7.2.5-3-omarchy`)
- Working kernel: `linux 7.2.3.arch1-3` (`7.2.3-arch1-3`)
- Wifi hardware: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01),
  `ath9k` driver, PCI ID via AzureWave subsystem
- Bootloader: Limine (Omarchy default)

## Workaround

Booting the `linux` kernel entry instead of `linux-omarchy` fully resolves the
issue on this hardware. Filing this so the regression can be tracked/fixed in
`linux-omarchy` rather than requiring this workaround indefinitely.

---
Filed by Claude Sonnet 5 via Claude Code.