### System details

Lenovo ThinkPad X1 Carbon Gen 13 21NS0012US (Lunar Lake), BIOS N4BET77W (1.47) 2026-06-30, Omarchy 4.0.2-1, kernel 7.1.9-arch1-2, SOF ADSPFW 2.14.1.1, topology sof-lnl-rt713-l0-rt1318-l1-2ch.tplg, PCI 0000:00:1f.3 Intel 8086:a828 sof-audio-pci-intel-lnl. Dual-boot Windows 11 on the same disk.

### What's wrong?

This was a basically brand-new X1 Carbon. I installed Omarchy and used it as a daily driver for **4–5 days** (themes, desktop setup). **Internal speakers worked.** Then they died during normal use and have not come back on Linux **or** Windows.

That timing is why I am filing this instead of assuming random silicon death. I am not claiming Omarchy uniquely fried a chip — I am asking for SoundWire/SOF expert eyes on a clash that left the speaker amp hung, because in-tree Linux documents that clash recovery is unimplemented. If a SoundWire clash during Speaker STOP can leave a soldered amp electrically hung across OS boundaries, that is a fleet risk (audio, and the same class of bus on other onboard devices), not just a mute/UCM ticket.

Companion kernel report for SoundWire/SOF maintainers: filing on `thesofproject/linux` as well; will cross-link.

#### What still works vs what does not

| Path | State |
|---|---|
| Internal speakers (RT1318 on SoundWire **link 1**) | **Silent.** `sdw:0:1:025d:1318:01` **UNATTACHED** |
| 3.5 mm jack (RT713 on **link 0**) | **Works** (after ThinkPad EC analog unmute; that mute is a separate headphone path) |
| USB-C / HDMI audio | **Works** |
| ALSA card `sofsoundwire` | **Exists.** Mixer/PCM can exist while the amp is UNATTACHED — `hw:0,2` is not proof of a live dataport |
| Windows Speakers endpoint | **Missing.** SST showed `FUNC_0713` only, no `FUNC_1318` |

This is **not** the X1C13 “no card / wrong topology / DRC widget” class (https://github.com/thesofproject/sof/issues/10755). The card was already there and speakers played.

This is **not** https://github.com/omacom/omarchy/issues/10010 / https://github.com/thesofproject/linux/issues/5914. That cousin clashes on one link with amps that **stay Attached and recover**. Here the amp never came back.

#### First failure

**Fri 2026-09-05 21:26:36 PDT**, on this Omarchy install:

1. Idle lock
2. Fingerprint reader USB storm on unlock
3. Speaker **STOP** (`trigger 0`) on a stream that was already running
4. SoundWire **link 1** `DATA_CLASH` + `CTRL_CLASH`
5. `chn_en` / `DPN_PortCtrl` **`-61`** (ENODATA, “msg ignored”)
6. clock-stop **`-110`**

After that, `sdw:0:1:025d:1318:01` stayed **UNATTACHED** across reboots, battery-pack disconnect, Windows, and clock-stop quirk changes. Link 0 (jack) stayed **Attached**.

#### Hardware view (Cadence PING, RPM-awake, valid)

Debugfs `/sys/kernel/debug/soundwire/master-0-{0,1}/intel-sdw/cdns-registers`. Sysfs `status` and hardware PING **agree**. This is not a false-UNATTACHED (https://github.com/thesofproject/linux/issues/3442).

| Link | `MCP_SLAVE_STAT` (0x50) | `MCP_INTSTAT` (0x44) | `MCP_CONTROL` | Clock |
|---|---|---|---|---|
| 0 jack RT713 | `0x1000` — device **6 Attached** | `0` | `0` | running |
| 1 amp RT1318 | `0x00000000` — **nobody, including device 0** | `0x80000400` IRQ + **CTRL_CLASH** | `0` (HW_RST not stuck) | running |

Cadence IRQ comment on bit 10: *“Slave is driving bit slot during control word.”* While the link-1 clock runs, `Bus clash for control word` is **continuous** (`dev_err_ratelimited` 10 lines / 5 s — that is printk, not a 5 s hardware event). First `start_bus` of every boot still clashes.

ACPI **does** describe the amp: `Device (SWD1)` `_ADR 0x000133025D131801` + nested `AF04`. No `_RST` / `_PR0` / GPIO reset on that node. Firmware knows the chip; the bus does not see Device0.

Live frame on link 1 is **50×8 / 19.2 MHz**; ACPI DisCo for LNK1 is **50×4 / 9.6 MHz**. Link 0 matches ACPI (50×4 / 9.6). Manager is up (not clock-stopped, INTMASK includes Device0 attach, SHIM PCM present).

In-tree docs match what we hit:

- https://www.kernel.org/doc/html/latest/driver-api/soundwire/error_handling.html — clash/parity is **log-only**; “the bus **might** be reset”; programming vs electrical clash cannot be distinguished; resetting individual slaves is **not** a viable recovery; command with no response = ignored; `ClockStopPrepare` timeouts are “symptoms of a faulty Slave … **likely impossible to recover from**.”
- `drivers/soundwire/bus.c` still has `TODO: reset bus` after slave clash/parity. That path never runs here because the amp never enumerates. Manager `CTRL_CLASH` is log + W1C in `sdw_cdns_irq()`.

Re-enumeration needs the amp to **PING as device 0**. Empty PING means https://github.com/thesofproject/linux/issues/5495 / Bard `bus_reset=1 if unattached` has nothing to re-enum. A slave that drives the control word cannot sample the manager’s control word, cannot see a clean 4096-cycle bus reset, and cannot join as Device0. Repeating `exit_reset` / `start_bus` re-hammers a contested wire.

#### What we already tried (please do not recommend repeating the hammers)

| Attempt | Result |
|---|---|
| Reboot, cold boot, BIOS battery disable + **physical pack unplug** (twice) | Still UNATTACHED, empty PING + CTRL_CLASH |
| Windows + Lenovo SST (`n4ba127w` is a PnP INF store, not amp NVM) | No Speakers device; `FUNC_0713` only |
| Windows MIPI SoundWire Controller disable/enable | No attach |
| Windows SST **OED** + SST **BUS** disable/enable, then full Linux boot | Linux PING **unchanged** |
| `sdw_clock_stop_quirks=2` (`CLK_STOP_TEARDOWN`) on **`snd-sof-intel-hda-generic`** (the correct module) | Clock-stop `-110` gone. First `start_bus` still clashes. Still UNATTACHED |
| Same quirk on `snd_sof_pci_intel_lnl` | **Ignored.** Live stayed 8 |
| Cadence debugfs `cdns-hw-reset` on link 1 | Still UNATTACHED; more PortCtrl. **Do not repeat** |
| PCI unbind/bind and PCI remove/rescan of `0000:00:1f.3` | Did not attach; SOF rebooted repeatedly. **Do not repeat** (https://github.com/thesofproject/linux/issues/4809) |
| sof#10755 2.11 firmware overlay | Loaded 2.11.1.1, still UNATTACHED (wrong class of bug) |
| RPM `power/control=on` | Did not create a PING responder. Unmasked **continuous** CTRL_CLASH until restored to `auto` |
| F10 UEFI Diagnostics | **This SKU has no audio module.** Already confirmed |

Kernel `7.1.9-arch1-2` **does** contain the LNL “enable interrupts before `exit_reset`” sequence. That only helps if Device0 PINGs and the IRQ missed the edge. `MCP_SLAVE_STAT` is 0.

#### Why this seems worth investigating

- Speakers **worked** on this unit under Omarchy.
- Failure was a **logged SoundWire clash** during Speaker STOP after s2idle/fingerprint activity, not a drop or a “never had a card” install.
- 4–5 days on a new machine is a short window for spontaneous amp death, and the hardware view is “something is still driving DATA during control slots,” not “chip absent / rail gated” (that is usually empty PING **without** clash).
- Linux has **no implemented clash recovery**. If a clash can leave an RT1318 electrically hung across OS boundaries, other X1C13 units on this topology can hit the same wall.

I can run further **read-only** dumps (Cadence IP bank at `ip_offset` 0x4000, journals, `omarchy-debug`). I am **not** going to write `cdns-hw-reset`, PCI-remove the HDA device, W1C `INTSTAT` from userspace, poke slave debugfs `go`, or write EC again unless a maintainer asks for a specific, bounded experiment.

#### Questions

1. Is there a host-side recovery for **empty PING including device 0 + continuous CTRL_CLASH** that is **not** another `sdw_cdns_exit_reset()` / `start_bus()`? Those already ran (quirk=2 resume path and debugfs hw-reset).
2. Does live link-1 **50×8 / 19.2 MHz** vs ACPI **50×4 / 9.6 MHz** matter once the slave is already fighting Col0, or is that a red herring?
3. Should a manager that sees continuous CTRL_CLASH **stop the clock** rather than keep generating frames? Holding RPM `on` made the clash continuous; autosuspend quieted the log by gating the link, not by attaching the amp.
4. If this is the unrecoverable electrical class (https://github.com/thesofproject/linux/issues/4535 won’t-fix, except they **had Device0**), please say so. Then the remaining path is Lenovo / system-board (RT1318 is soldered, HMM FRU **#8**; speaker assembly FRU **#7** does not replace the amp IC).
5. For Omarchy: is there anything this distro should **stop doing** on Lunar Lake SoundWire (RPM hammering `start_bus` after clash, PCI-level “recover” scripts, etc.) so the next X1C13 does not deepen a hung link?

Happy to capture whatever log/dump is actually useful. Please do **not** suggest F10 audio, sof#10755 overlay, or masking SoundWire link 1 (`sdw_link_mask` is the inverse case: https://github.com/thesofproject/linux/issues/4353 ghost link).