### System details

MacBookPro15,1 (2018 15" T2, Mac-937A206F2EE63C01), Omarchy `omarchy-dev 4.0.0.r1732.g864b0d0-1` (4.0.0.alpha Quattro), kernel `7.1.8-arch1-Watanare-T2-2-t2`

### What's wrong?

## Summary

On a **MacBookPro15,1** (2018 15", T2), suspend is unusable in either sleep mode:

- **`deep` / S3** (currently pinned by Omarchy for all T2 Macs): the machine enters sleep and **never resumes**. Power-button hold required.
- **`s2idle`**: the first suspend/resume works, but Thunderbolt fails to resume and takes both TB-attached xHCI controllers down with it. The **second** suspend in the same boot then never returns.

Net effect: every suspend eventually costs a forced power-off. Over this drive's life that is **137 unsafe shutdowns across 320 power cycles (43%)**, with vfat dirty bits and corrupted journals on the following boot.

Migration `1785944594` (from #6559 / #6562) pins `mem_sleep_default=deep` for all T2 Macs. On this model that pins the strictly worse of two bad options — `deep` fails on the *first* suspend, `s2idle` at least survives one.

**On causality, to be fair to #6562:** the failures predate that migration. Earlier boots carried no `mem_sleep_default` at all and still used deep, because deep is the kernel's default when the platform advertises S3. #6562 did not introduce this. What it does is make the failing mode explicit and harder to escape — an affected user must now edit `/etc/limine-entry-tool.d/t2-mac.conf` and rebuild the UKI to reach `s2idle`.

## Environment

| | |
|---|---|
| Model | MacBookPro15,1 (`Mac-937A206F2EE63C01`) |
| BIOS | 2103.100.6.0.0 (iBridge 23.16.15067.0.0) |
| Omarchy | `omarchy-dev 4.0.0.r1732.g864b0d0-1` (4.0.0.alpha, Quattro) |
| Kernel | `7.1.8-arch1-Watanare-T2-2-t2` |
| `tiny-dfr` | not installed (correctly removed by the same migration) |

## 1. `deep` / S3 never resumes

Suspend begins, `t2bce_vhci` fails to quiesce, the machine enters S3 anyway and never returns:

```
systemd[1]: Starting System Suspend...
kernel: t2bce_vhci: Possible desync, cmd cancel timed out     <-- repeats every ~3s for 40s
kernel: hub 7-0:1.0: hub_ext_port_status failed (err = -110)  <-- -110 = ETIMEDOUT
kernel: t2bce_vhci: [00] pause timeout waiting for 1 outputs
systemd-sleep[29246]: Performing sleep operation 'suspend'...
<journal ends — no resume; power button hold required>
```

Note this occurs with `tiny-dfr` already absent, so it is not the stale-descriptor problem the migration's `tiny-dfr` removal addresses.

Boot-termination comparison — failed resumes end mid-suspend, clean shutdowns end with filesystem unmounts:

| Boot | Ended with | Outcome |
|---|---|---|
| -6 | `Unmounted /home` … | clean |
| -5 | `Performing sleep operation 'suspend'` / `PM: suspend entry (deep)` | **never resumed** |
| -4 | `Deactivating swap` … | clean |
| -3 | `Unmounted /tmp` … | clean |
| -2 | `Performing sleep operation 'suspend'` | **never resumed** |
| -1 | `Unmounted /var/cache/pacman/pkg` … | clean |

## 2. `s2idle` survives exactly one cycle

With `mem_sleep_default=s2idle` set persistently and verified in `/proc/cmdline`:

**Cycle 1 — resumes.** `t2bce` itself is clean throughout (`status=0` on every callback):

```
kernel: PM: suspend entry (s2idle)
kernel: t2bce_vhci: bus_suspend exit status=0
kernel: t2bce_core: suspend: exit status=0 stateful_valid=1
kernel: t2bce_core: resume: exit status=0 path=stateful
kernel: t2bce_vhci: stateful resume exit status=0
systemd-sleep: System returned from sleep operation 'suspend'.
```

**But Thunderbolt does not resume**, and both TB-attached xHCI controllers die:

```
kernel: WARNING: drivers/thunderbolt/ctl.c:1131 at tb_cfg_read+0x94/0xf0 [thunderbolt]
kernel: WARNING: drivers/thunderbolt/ctl.c:1157 at tb_cfg_write+0x94/0xf0 [thunderbolt]
  (~16 such warnings, call path:
   tb_resume_noirq -> tb_domain_resume_noirq -> tb_switch_discover_tunnels
   -> tb_tunnel_discover_pci -> tb_pci_port_is_enabled)

kernel: xhci_hcd 0000:07:00.0: Controller not ready at resume -19
kernel: xhci_hcd 0000:07:00.0: HC died; cleaning up
kernel: xhci_hcd 0000:07:00.0: PM: failed to resume: error -19
kernel: xhci_hcd 0000:7d:00.0: Controller not ready at resume -19
kernel: xhci_hcd 0000:7d:00.0: HC died; cleaning up
kernel: xhci_hcd 0000:7d:00.0: PM: failed to resume: error -19
```

USB-C is dead from this point until reboot (`lsusb` returns nothing).

**Cycle 2 — never returns.** Same boot, same session, ~7 minutes later:

```
15:12:42  systemd-logind: Lid closed.
15:12:43  systemd-sleep[20160]: Performing sleep operation 'suspend'...
15:12:43  kernel: PM: suspend entry (s2idle)
<journal ends — forced power-off required>
```

Next boot:

```
systemd-fsck: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
systemd-journald: system.journal corrupted or uncleanly shut down, renaming and replacing.
systemd-journald: user-1000.journal corrupted or uncleanly shut down, renaming and replacing.
```

This reproduced twice: once via direct `systemctl suspend` followed by a lid close, and once via two consecutive lid closes.

The same pattern also hangs **shutdown**: a reboot issued after one suspend/resume cycle never reached `systemd-shutdown` and required a power-button hold.

## 3. Impact

NVMe SMART, whole-drive lifetime:

```
power_cycles      : 320
unsafe_shutdowns  : 137     (43%)
```

No data loss so far — btrfs reports zero corruption/generation errors — but this repeatedly yanks power from a mounted filesystem.

## Ruled out: `pcie_ports=compat`

I suspected this flag (it disables native PCIe port services, which Thunderbolt depends on for resume) and tested it. **It is not the cause** — with it removed and the UKI rebuilt, the `tb_cfg_read` warnings and `xhci_hcd ... -19` failures were byte-for-byte identical. Recording this so nobody repeats the dead end.

**However, a real migration bug surfaced while testing it.** Migration `1785944594` rewrites `pcie_ports=compat` only in `/etc/limine-entry-tool.d/t2-mac.conf`:

```bash
sudo sed -i 's/pcie_ports=compat/pm_async=off mem_sleep_default=deep/' "$limine_conf"
```

But an older, identical flag also lives in `/etc/default/limine`:

```
KERNEL_CMDLINE[default]+=" intel_iommu=on iommu=pt pcie_ports=compat"
```

That copy is never touched, so the resulting cmdline still carries `pcie_ports=compat` alongside the new flags. The migration does not achieve what it intends on installs that have both. Independent of my symptoms, this looks worth fixing.

## Suggestions

1. **Gate the sleep mode on model** rather than applying `deep` to all T2 Macs. #6562's tester confirmed deep works on their hardware, so this is model-specific. On 15,1, `s2idle` is strictly better (one working cycle vs zero):

   ```bash
   case "$(dmidecode -s system-product-name)" in
     MacBookPro15,*) sleep_mode=s2idle ;;
     *)              sleep_mode=deep   ;;
   esac
   KERNEL_CMDLINE[default]+=" intel_iommu=on iommu=pt pm_async=off mem_sleep_default=$sleep_mode"
   ```

2. **Fix the migration** to also strip `pcie_ports=compat` from `/etc/default/limine`, or de-duplicate the T2 cmdline into one source of truth.

3. **The Thunderbolt resume failure is the actual blocker** and may belong upstream (kernel `drivers/thunderbolt`) rather than here. Neither sleep mode makes suspend safe on this model while xHCI dies on every resume. Flagging it in case it is known, or affects other T2 models.

4. Failing all of the above, **documenting the override** would help — affected users currently have to reverse-engineer the cmdline and rebuild the UKI to try `s2idle`.

I'm happy to test patches or collect the same data on request.

## Reproduction

```bash
# Current (failing) default
cat /sys/power/mem_sleep          # s2idle [deep]
systemctl suspend                 # enters sleep, never resumes

# s2idle: runtime only, reverts on reboot
sudo sh -c 'echo s2idle > /sys/power/mem_sleep'
cat /sys/power/mem_sleep          # [s2idle] deep
systemctl suspend                 # cycle 1 resumes
                                  # -> check dmesg for xhci_hcd -19 / HC died
systemctl suspend                 # cycle 2 never returns
```