### System details

ASUS ExpertBook B9406CAA, Intel Arc B390 [8086:b080], Samsung Display Corp ATNA40LE01-0 (eDP-1, 2880x1800), PixArt haptic touchpad 093A:4F05 on ACPI ASCP1D80 (`i2c_designware.0`). Omarchy 4.0.4-1. Running kernel `linux 7.2.3-arch1-3` (linux-omarchy 7.2.5-3 is installed and was not the kernel that froze). Hyprland.

Related: #5423 is the older Panel Replay first-frame stall and is a different bug. #11245 is the same kernel generation wedging a different I2C-HID touchpad (ELAN).

### What's wrong?

The whole desktop freezes after a long session. The touchpad dies with it. Input and the picture stop updating. A reboot is what recovered it. This has now happened on three consecutive boots of linux 7.2.3, and only at the end of the session. The boot that followed the Omarchy 4.0.4 update (15–18 Sep) did not log it. One of the three started 41 seconds after resume from suspend.

Kernel signature, in order, on `i2c_designware.0`:

```
i2c_designware i2c_designware.0: controller timed out
i2c_designware i2c_designware.0: timeout in disabling adapter
i2c_designware i2c_designware.0: timeout waiting for bus ready
```

The last line repeats about 20 times a second until reboot (3935, 13382, and 14186 lines on the three boots). `irq/*-ASCP1D80:00` stays in D-state, and `kworker/*+i915_flip` does too, which is why the compositor looks frozen rather than only the cursor dying. Unloading the touchpad driver does not recover a thread that is already stuck. The 25 Sep wedge was preceded, about eight minutes earlier, by repeated `hid-sensor-hub 001F:8087:0AC2: timeout waiting for response from ISHTP device`. There was no `Timed out waiting PSR idle state` and no DSB timeout in these journals.

The Sep 22 case is the clearest trigger: `PM: suspend exit` at 09:33:22, `controller timed out` at 09:33:51, then the flood.

### How to tell, and how to recover

```sh
journalctl -k -b | grep -E 'controller timed out|timeout waiting for bus ready|ISHTP device'
ps -eo stat,pid,wchan:24,cmd | awk 'NR==1 || $2 ~ /^D/'
```

While the session still accepts a command:

```sh
omarchy restart trackpad
```

That unbinds and rebinds `i2c_hid_acpi`. If the rebind hangs, or the picture is already frozen, reboot. Do not `rmmod` a driver whose IRQ thread is stuck in D-state. A normal reboot from that state can sit on the last frame until the machine actually powers off.

Do not poll `acpitz` or ASUS `hwmon` fan and temperature nodes from a status bar. Those ACPI reads take the embedded controller and stall this I2C bus and the sensor hub. `touchpad-fix` / the libinput pressure quirk does not prevent this. That quirk only stops libinput discarding motion as a touch jump.

### What this is not

Omarchy's shipped `xe.enable_panel_replay=0` workaround for this panel (#5423, `fix-asus-ptl-b9406-display.sh`) was not on the cmdline for these three boots. A third-party module (`asus-expertbook-linux` display-fix 1.3) had archived that drop-in on the theory that Linux 7.2 fixed Panel Replay. These freezes did not log the old PSR-idle error, so the missing switch is not presented as the cause. It is still the wrong thing to delete: https://github.com/burakgon/asus-expertbook-linux/pull/22 restores it and writes down the rebind.

I do not have a captured `omarchy debug` log from inside the wedge. The session was not usable by then. The lines above are from `journalctl -k` on the following boot.