### System details

Intel Core i5-9300H, Intel UHD 630 + NVIDIA GTX 1650 Mobile, **Intel Wi-Fi 6E AX210** (`8086:2725`, `iwlwifi`), ASUS TUF Gaming FX505GT, BIOS FX505GT.311 (2021-02-08), Omarchy 4.0.4-1, `linux-omarchy` 7.2.5-3.

### What's wrong?

On cold boots, the AX210 Wi-Fi card is knocked off the PCIe bus about two seconds into boot and Wi-Fi is dead for the entire boot. A reboot clears it — 2 for 2 so far.

The trigger is the Omarchy kernel enabling Intel IOMMU DMA translation, which stock Arch leaves off:

```
$ grep INTEL_IOMMU_DEFAULT_ON /usr/lib/modules/7.2.5-3-omarchy/build/.config
CONFIG_INTEL_IOMMU_DEFAULT_ON=y
$ grep INTEL_IOMMU_DEFAULT_ON /usr/lib/modules/7.2.3-arch1-3/build/.config
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
```

This is the same config change already reported in #12550 (amdgpu black screen) and #12119 (NVMe / Apple SPI / amdgpu), both resolved with `intel_iommu=off`. **This is a third device class affected, on non-Apple hardware** — which is why I'm filing rather than commenting on those.

`/proc/cmdline` carries no `intel_iommu=` or `iommu=`, so the kernel config default is what governs.

#### What happens

VT-d blocks a DMA read from the card, and **79 µs later** the card raises a fatal PCIe error:

```
18:59:17.331793 kernel: DMAR: [DMA Read NO_PASID] Request device [0000:04:00.0]
                        fault addr 0xfebff000 [fault reason 0x06] PTE Read access is not set
18:59:17.331872 kernel: pcieport 0000:00:1d.5: DPC: containment event, status:0x1f05,
                        ERR_FATAL received from 0000:04:00.0
18:59:17.332795 kernel: iwlwifi 0000:04:00.0: AER: can't recover (no error_detected callback)
18:59:17.453981 kernel: pcieport 0000:00:1d.5: AER: device recovery failed
```

`iwlwifi` registers no `pci_error_handlers`, so nothing resets the card. Its config space then shows Command `0x0000` and BAR0 cleared, and every MMIO read returns `0xffffffff`. The rest of the boot is 22 × `Failed to start RT ucode: -110`, 11 × `HW error, resetting before reading`, all status registers `0x5a5a5a5a`, six × `Could not set interface wlp4s0 flags (UP): Connection timed out`, five supplicant re-acquires, then:

```
NetworkManager: <info> device (wlp4s0): supplicant interface keeps failing, giving up
```

`wlp4s0` never leaves `unavailable`, so no connection profile is ever attempted — from the user's side it looks like "Wi-Fi is broken", but it never gets as far as a network. Toggling airplane mode cannot help, since rfkill does not re-probe a contained PCIe device.

#### Mechanism, decoded

`iwlwifi` dumps its own AER capability structure into the journal on a failed transaction. Both failing boots produced identical values apart from the TLP tag byte (`0x04` here, `0x07` in the other boot):

```
iwlwifi 0000:04:00.0: 00000000: 14c10001 00140000 00000000 00462031 00002000 00002000 00000012 0a000000
iwlwifi 0000:04:00.0: 00000020: 00002080 04000400 00000000
```

| Register | Value | Meaning |
|---|---|---|
| Uncorrectable Error Status | `0x00140000` | bit 18 **Malformed TLP** + bit 20 **Unsupported Request** |
| Uncorrectable Error Severity | `0x00462031` | bit 18 set ⇒ **Malformed TLP is fatal**; bit 20 clear ⇒ UR non-fatal |
| Header Log DW0 | `0x0a000000` | Fmt/Type `0x0a` = `Cpl` (completion, 3 DW, no data) |
| Header Log DW1 | `0x00002080` | Completer ID `0000`, **Cpl status 1 = UR**, byte count 128 |
| Header Log DW2 | `0x04000400` | **Requester ID `0400` = `0000:04:00.0`** — the card itself |

So: the card issues a DMA read → the IOMMU has no valid mapping → the root complex returns a completion with status `Unsupported Request` → the card logs that as `Malformed TLP`, which its severity register classes as fatal → `ERR_FATAL` → DPC containment. The requester ID decoding to the card's own BDF, and the `UR` status matching the independently logged DMAR fault, cross-check the decode.

The faulting addresses (`0xfeb2a000`, `0xfeba8000`, `0xfebff000`) all sit in one 1 MB band immediately below this domain's reserved MSI region (`/sys/kernel/iommu_groups/17/reserved_regions` → `0xfee00000-0xfeefffff msi`), and they differ between boots. That reads as IOVAs from the top of the 32-bit IOVA window rather than stale physical addresses — i.e. **the underlying bug looks like an `iwlwifi` mapping-validity problem that the IOMMU exposes**, not something Omarchy caused. Filing it here because the config default is what decides whether users hit it.

#### Before / after

`linux-omarchy` was installed on this machine by the 4.0.3 → 4.0.4 update on 2026-09-16, via migration `1789325478.sh` ("Install the Omarchy kernel and make it the first Limine boot entry"). Before that the machine ran stock Arch kernels.

| Kernel | Cold boots (>5 h powered off) | Wi-Fi failures |
|---|---|---|
| Arch `7.1.9-arch1-2` / `7.2.3-arch1-3` | 26 | **0** |
| `linux-omarchy` 7.2.5-3 | 7 | **2** |

DMA remapping really was inactive before, on two independent markers — `Intel(R) Virtualization Technology for Directed I/O` appears 0 times on the Arch-kernel boots and once on every `linux-omarchy` boot, and `Adding to iommu group` goes from **0** devices to **24**. Across all 56 retained boots, every DMAR fault belongs to one of the two Wi-Fi failures.

First failure was the **first cold boot** after the migration (2026-09-17); second was 2026-09-23.

#### Hardware is not the problem

- **Zero** PCIe correctable errors in all 56 retained boots — no `BadTLP`, `BadDLLP`, `RxErr`, replay-timer timeout, or surprise-down on the card or its root port. A failing M.2 module would show these.
- `LnkSta: Speed 5GT/s, Width x1` matches `LnkCap` exactly — no train-down.
- Firmware is `89.f7dcb3ee.0 ty-a0-gf-a0-89.ucode`, the newest in `linux-firmware` 20260810-2.

#### What I am *not* claiming

- **n = 2.** Five of the seven cold boots on `linux-omarchy` were fine, so IOMMU-on is necessary but not sufficient — some timing factor decides which cold boots fail.
- **No counter-test has been run.** I have not booted with `intel_iommu=off` or on the Arch kernel and observed cold boots since, so the before/after above is observational, not a control. Nothing on this machine has been changed.
- Enabling VT-d also changes *what addresses the driver hands the device* (IOVAs vs physical), so the IOMMU may have created the condition rather than merely revealed it. I can't distinguish those from this evidence.

#### Suggestion

Not asking anyone to fix `iwlwifi`. But this is now three unrelated device classes broken by one config default, on three different machines, within a week of 4.0.4 shipping — so it may be worth reconsidering whether `CONFIG_INTEL_IOMMU_DEFAULT_ON` is the right default for a general-purpose distro kernel, or at minimum mentioning the `intel_iommu=off` escape hatch where users will find it when a device stops working after the kernel migration.

One thing the migration gets right and that's worth keeping: it leaves the previous kernel installed and keeps a `*` wildcard in `BOOT_ORDER`, so the Arch kernel remains selectable in Limine as a fallback.

Happy to attach full `omarchy-debug` output, the complete `journalctl -b -k` for either failing boot, or to run a specific test if it would help.