## Summary

After updating to Omarchy 4.0.4-1 and `linux-omarchy` 7.2.5-3, the bespoke kernel does not boot correctly on a 2016 15-inch MacBook Pro with Touch Bar/T1 chip (`MacBookPro13,3`). The stock Arch kernel 7.2.3 boots on the same system with the same PCI parameters.

Adding `intel_iommu=off` to the `linux-omarchy` command line fixes NVMe discovery, Apple SPI keyboard/trackpad operation, and AMD graphics initialization. The machine then boots normally with the internal panel driven by `amdgpu`.

The 2017 15-inch T1 model (`MacBookPro14,3`) has a closely related platform and AMD discrete GPU, so it may be affected as well. That model has not been tested here.

## Hardware

- 2016 15-inch Apple MacBook Pro with Touch Bar/T1 chip
- Model identifiers: MacBookPro13,3 / Mac-A5C67F76ED83108C
- Intel Core i7-6700HQ
- Intel HD Graphics 530 (`8086:191b`)
- AMD Radeon Pro 450 / Baffin (`1002:67ef`)
- Samsung/Apple NVMe SSD SM0256L (`144d:a804`)
- Apple SPI keyboard and trackpad (`APP000D`)
- Firmware: Apple 529.120.1.0.0 dated 2024-03-14

## Software

- Omarchy 4.0.4-1
- Failing kernel: `linux-omarchy` 7.2.5-3
- Working comparison kernel: `linux` 7.2.3.arch1-3
- Limine 12.8.0-1

## Steps to reproduce

1. Install/update to `linux-omarchy` 7.2.5-3.
2. Boot its Limine entry on a MacBookPro13,3.
3. Existing PCI parameters are `pci=nocrs,realloc`; these are also used by the working stock kernel.

## Actual behavior without `intel_iommu=off`

The initial boot goes black and appears to hang during AMD initialization. With verbose output enabled, the last visible line is around:

```text
amdgpu 0000:01:00.0: [drm] VCE enabled in VM mode
```

To isolate the graphics path, I temporarily blacklisted `amdgpu`. The kernel then progressed further but failed to discover the NVMe root device:

```text
Waiting 10 seconds for device /dev/disk/by-uuid/...
ERROR: device '/dev/mapper/omarchy_root' not found. Skipping fsck.
mount: /new_root: special device /dev/mapper/omarchy_root does not exist
ERROR: Failed to mount '/dev/mapper/omarchy_root' on real root
You are now being dropped into an emergency shell.
```

Pressing a key in that initramfs shell caused an interrupt/log flood:

```text
applespi spi-APP000D:00: Error reading from device: -12
```

`-12` is `ENOMEM`. The messages repeated rapidly for each keyboard event.

The custom UKI was checked and does contain `nvme.ko`, `nvme-core.ko`, `dm-crypt.ko`, and `cryptsetup`, so the missing root device was not caused by an omitted initramfs module.

## Diagnostic results

| `linux-omarchy` parameters | Result |
|---|---|
| Default IOMMU behavior, AMD enabled | Black screen/hang during `amdgpu` initialization |
| Default IOMMU behavior, `amdgpu` blacklisted | NVMe absent; initramfs emergency shell; Apple SPI floods error `-12` |
| `intel_iommu=off`, `amdgpu` blacklisted | NVMe and Apple SPI work; system boots using simpledrm output and Intel rendering |
| `intel_iommu=off`, AMD enabled | Full successful boot; NVMe, Apple SPI, and AMD internal display all work |

Successful boot messages include:

```text
DMAR: IOMMU disabled
applespi spi-APP000D:00: modeswitch done.
nvme nvme0: pci function 0000:02:00.0
nvme nvme0: 1/0/0 default/read/poll queues
[drm] Initialized amdgpu 3.64.0 for 0000:01:00.0 on minor 1
amdgpu 0000:01:00.0: [drm] fb0: amdgpudrmfb frame buffer device
```

The resulting desktop uses the AMD GPU and the internal `eDP-1` panel at 2880x1800.

## Relevant kernel configuration difference

The working Arch kernel configuration contains:

```text
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
# CONFIG_SWIOTLB_DYNAMIC is not set
```

The failing bespoke kernel contains:

```text
CONFIG_INTEL_IOMMU_DEFAULT_ON=y
CONFIG_SWIOTLB_DYNAMIC=y
```

The most direct explanation is that default-on Intel DMA remapping is incompatible with this MacBook firmware/hardware combination. Disabling it at boot fixes all affected devices.

## Workaround

Add `intel_iommu=off` to the `linux-omarchy` Limine command line and rebuild with `limine-update`.

## Expected behavior

`linux-omarchy` should boot on this hardware without a black screen or loss of NVMe and Apple SPI devices. Possible fixes could include disabling `CONFIG_INTEL_IOMMU_DEFAULT_ON` in the kernel package, or applying an Apple-model-specific boot parameter/workaround.

---

This bug report and diagnostic workaround were prepared with gpt-5.6-sol high.