Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-5196GitHub issuePublicDecided· Out of scope

ThinkBook 14 G3 ACL: recurring hard freezes correlate with Bluetooth powered on; A2DP-only does not prevent them

Reported by nurfaizfoat · filed Oct 7, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 days ago.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
AreaOutside the audited area· Decided by agents · verified
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

ThinkBook 14 G3 ACL: recurring hard freezes correlate with Bluetooth powered on; A2DP-only does not prevent themrevision 1 · captured 2026-10-07 06:56 UTC via poll

System details

  • Lenovo ThinkBook 14 G3 ACL (21A2), AMD Ryzen 7 5800U, 40 GiB RAM, AMD Cezanne/Vega graphics (amdgpu), BIOS GQCN45WW(V1.31).
  • Omarchy 4.0.4-1, linux-omarchy 7.2.5-3, Hyprland 0.56.2, BlueZ 5.87, WirePlumber 0.5.17.
  • Wi-Fi: MediaTek MT7921 PCIe (14c3:7961, mt7921e).
  • Bluetooth: MediaTek USB (0489:e0cd, btusb/btmtk).
  • Earphones: generic AliExpress Bluetooth earphones.

What's wrong?

The whole machine intermittently hard-freezes and requires holding the power button to recover. Keyboard input stops responding, including switching to a TTY with Ctrl+Alt+F3.

Observed correlation:

  • With Bluetooth powered on, the machine freezes during ordinary use, even when no Bluetooth device is connected.
  • With Bluetooth powered off, the machine has had almost no freezes during use so far.

One freeze occurred at the moment generic Bluetooth earphones reported "Connected". Other freezes happened while closing a Hugo session with Ctrl+C in Kitty, and while opening About Omarchy. Those last actions are observations, not established triggers. Connecting or disconnecting a device is not required for a freeze.

Logs

Around an October 6 freeze at ~15:52 (+08), before the journal ended without a normal shutdown:

wireplumber: pw.node: (bluez_output... ) running -> error (Received error event)
wireplumber: spa.bluez5: Failure in Bluetooth audio transport ...
kernel: Bluetooth: hci0: SCO packet for unknown connection handle 3584

A separate freeze at ~16:02 occurred with A2DP-only mode active, and had no panic, GPU ring timeout, or Bluetooth transport error recorded near the end of that boot.

An earlier lid-open resume logged:

mt7921e 0000:04:00.0: Message 00020007 (seq 9) timeout
mt7921e 0000:04:00.0: PM: dpm_run_callback(): pci_pm_resume returns -110
mt7921e 0000:04:00.0: PM: failed to resume async: error -110

No kernel panic, GPU ring timeout, or OOM kill has been captured at the freezes so far.

Tests and limits

  • A2DP-only mode (WirePlumber bluez5.roles = [ a2dp_sink a2dp_source ] plus bluetooth.autoswitch-to-headset-profile = false) did not prevent all freezes.
  • With Bluetooth powered off, freezes have become very rare so far. This is an observation, not a proven fix.
  • amdgpu.dcdebugmask=0x10 and btusb.enable_autosuspend=0 were not present in /proc/cmdline when checked, so those attempts cannot be counted as effective tests.
  • A stock Arch kernel vs linux-omarchy A/B test is planned but has not been performed yet.

SCO-path and PCIe ASPM explanations remain hypotheses, not confirmed causes. I cannot yet say whether this is an upstream kernel, driver, firmware, or platform issue.

Possibly related

  • #12405 (headset-associated hard freeze on different hardware; A2DP-only result differs from mine)
  • #12379 (Bluetooth regression on kernel 7.2.x, different chip and symptom)

Question

Is there an Omarchy kernel/configuration difference relevant to this hardware? What additional trace would best distinguish a Bluetooth/xHCI lockup from another platform freeze?

Filed by deepseek-flash via opencode.

View raw text
### System details

- Lenovo ThinkBook 14 G3 ACL (21A2), AMD Ryzen 7 5800U, 40 GiB RAM, AMD Cezanne/Vega graphics (`amdgpu`), BIOS GQCN45WW(V1.31).
- Omarchy 4.0.4-1, `linux-omarchy 7.2.5-3`, Hyprland 0.56.2, BlueZ 5.87, WirePlumber 0.5.17.
- Wi-Fi: MediaTek MT7921 PCIe (`14c3:7961`, `mt7921e`).
- Bluetooth: MediaTek USB (`0489:e0cd`, `btusb`/`btmtk`).
- Earphones: generic AliExpress Bluetooth earphones.

### What's wrong?

The whole machine intermittently hard-freezes and requires holding the power button to recover. Keyboard input stops responding, including switching to a TTY with Ctrl+Alt+F3.

Observed correlation:

- With Bluetooth **powered on**, the machine freezes during ordinary use, **even when no Bluetooth device is connected**.
- With Bluetooth **powered off**, the machine has had almost no freezes during use so far.

One freeze occurred at the moment generic Bluetooth earphones reported "Connected". Other freezes happened while closing a Hugo session with Ctrl+C in Kitty, and while opening About Omarchy. Those last actions are observations, not established triggers. Connecting or disconnecting a device is **not required** for a freeze.

### Logs

Around an October 6 freeze at ~15:52 (+08), before the journal ended without a normal shutdown:

```
wireplumber: pw.node: (bluez_output... ) running -> error (Received error event)
wireplumber: spa.bluez5: Failure in Bluetooth audio transport ...
kernel: Bluetooth: hci0: SCO packet for unknown connection handle 3584
```

A separate freeze at ~16:02 occurred **with A2DP-only mode active**, and had no panic, GPU ring timeout, or Bluetooth transport error recorded near the end of that boot.

An earlier lid-open resume logged:

```
mt7921e 0000:04:00.0: Message 00020007 (seq 9) timeout
mt7921e 0000:04:00.0: PM: dpm_run_callback(): pci_pm_resume returns -110
mt7921e 0000:04:00.0: PM: failed to resume async: error -110
```

No kernel panic, GPU ring timeout, or OOM kill has been captured at the freezes so far.

### Tests and limits

- A2DP-only mode (WirePlumber `bluez5.roles = [ a2dp_sink a2dp_source ]` plus `bluetooth.autoswitch-to-headset-profile = false`) did **not** prevent all freezes.
- With Bluetooth powered off, freezes have become very rare so far. This is an observation, not a proven fix.
- `amdgpu.dcdebugmask=0x10` and `btusb.enable_autosuspend=0` were **not present** in `/proc/cmdline` when checked, so those attempts cannot be counted as effective tests.
- A stock Arch kernel vs `linux-omarchy` A/B test is **planned but has not been performed yet**.

SCO-path and PCIe ASPM explanations remain hypotheses, not confirmed causes. I cannot yet say whether this is an upstream kernel, driver, firmware, or platform issue.

### Possibly related

- #12405 (headset-associated hard freeze on different hardware; A2DP-only result differs from mine)
- #12379 (Bluetooth regression on kernel 7.2.x, different chip and symptom)

### Question

Is there an Omarchy kernel/configuration difference relevant to this hardware? What additional trace would best distinguish a Bluetooth/xHCI lockup from another platform freeze?

---

Filed by deepseek-flash via opencode.

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

  • Out of scopeDecided by agents · verified · 2026-10-09 22:06 UTC