## System details

- **Omarchy:** `4.0.4-1`
- **Hardware:** Apple MacBook Air, `MacBookAir8,2`
- **CPU:** Intel Core i5-8210Y, 2 cores / 4 threads
- **GPU:** Intel UHD Graphics 617, `i915`
- **RAM:** 16 GB
- **Kernel:** `7.2.6-arch2-Watanare-T2-2-t2`
- **linux-t2 package:** `7.2.6.arch2-2`
- **t2fanrd:** `r16.48baf96-1`
- **Power management:** `power-profiles-daemon`, power-saver profile; `thermald` active
- Running on battery when investigated

## What's wrong?

`t2fanrd.service` was active, but the SMC's manual fan-control flag was disabled. The fan was running around **3,200–3,500 RPM** while CPU package temperatures measured **91–96°C**.

The existing `/etc/t2fand.conf` specifies:

```ini
[Fan1]
low_temp=55
high_temp=75
speed_curve=linear
always_full_speed=false
```

The fan's reported maximum is **8,000 RPM**, so the daemon's configured curve should request maximum speed above 75°C.

Observed sysfs values included:

```text
/sys/bus/acpi/devices/APP0001:00/fan1_manual: 0
/sys/bus/acpi/devices/APP0001:00/fan1_input: 3252
/sys/bus/acpi/devices/APP0001:00/fan1_output: 3203
/sys/bus/acpi/devices/APP0001:00/fan1_max: 8000
```

The CPU package thermal-throttling counter increased from **2,892 to 3,120** during investigation.

## Observed sequence and suspected trigger

1. `t2fanrd` started at boot.
2. The machine subsequently suspended and resumed.
3. No daemon restart appeared between boot and the discovery of disabled manual fan control.
4. Restarting the daemon restored manual control immediately.

**Suspend/resume is a suspected trigger, not a confirmed reproduction.** The failure was observed and recovery verified, but another suspend/resume cycle has not been tested.

The [daemon source at the packaged revision](https://github.com/GnomedDev/t2fanrd/blob/48baf96/src/main.rs) enables manual control during startup. If firmware or the driver clears that state during sleep, the running daemon appears not to reassert it.

## Expected behavior

The configured fan policy should remain effective—or be restored—after resume. An active daemon should not silently remain unable to apply its cooling policy.

## Verified recovery

Running:

```bash
sudo systemctl restart t2fanrd.service
```

changed `fan1_manual` from `0` to `1`, set the target to **8,000 RPM**, and produced measured fan speeds around **7,900–8,100 RPM**.

Throttling stopped during an initial 30-second observation, but returned during a later sample despite full fan speed. Therefore, this report concerns **lost fan control**, not a claim that restoring it eliminates all thermal throttling.

## Local workaround

Added a oneshot systemd service that runs:

```bash
/usr/bin/systemctl try-restart t2fanrd.service
```

after the corresponding systemd sleep service completes. It is enabled for suspend, hibernate, hybrid sleep, and suspend-then-hibernate.

Systemd unit validation and manually invoking the helper passed. **Automatic execution after actual resume remains untested.** No fan-curve or CPU power-limit changes were made.

## Omarchy integration

The installed `install/hardware/apple/fix-t2.sh` installs and enables `t2fanrd` and writes the above fan policy.

Could the T2 integration ensure that fan control is restored after resume, or coordinate an upstream daemon fix if that is the appropriate layer?

## Diagnostics note

`omarchy debug --no-sudo --print` returned “Unknown Omarchy command” on this installation. The observations above came from `systemctl`, `journalctl`, `sensors`, package versions, and sysfs.