#1135354 linux-image-7.0.3+deb14-amd64: Conexant SN6140: UCM returns EBUSY at cold boot, audio falls back to dummy output

Package:
src:linux
Source:
src:linux
Submitter:
Yu Rui
Date:
2026-05-12 12:31:04 UTC
Severity:
normal
Tags:
#1135354#5
Date:
2026-05-01 14:27:26 UTC
From:
To:
Dear Maintainer,

After cold boot, the Conexant SN6140 audio codec on this AMD platform
fails to initialize correctly when PipeWire/WirePlumber probes it via
ALSA UCM. The speaker and headphone output are unavailable, and the
system falls back to dummy output.

Hardware:
  Laptop: HONOR BRN-HXXB
  HDA Controller: AMD Ryzen HD Audio [1022:15e3]
  Codec: Conexant SN6140 (Vendor ID 0x14f11f87, Subsystem 0x1ee7204b)

The PipeWire log shows:
  spa.alsa: '_ucm0001.hw:Generic_1':
    playback open failed: Device or resource busy

WirePlumber then fails to create the speaker sink:
  s-monitors: Failed to create
  alsa_output.pci-0000_c1_00.6.HiFi__Speaker__sink:
  Object activation aborted: PipeWire proxy destroyed

Restarting WirePlumber after the system has been up for a few seconds
(systemctl --user restart wireplumber) consistently fixes the issue.
This confirms the codec simply needs more time to initialize than the
driver currently allows.

Setting snd_hda_intel.power_save=0 does not resolve the issue.
A 4-second delay before WirePlumber startup works around it.

Root cause appears to be in the kernel HDA driver: the Conexant SN6140
codec takes longer to complete initialization than snd_hda_intel
expects, but the driver reports the card to userspace (udev event)
before the codec is fully ready.

#1135354#10
Date:
2026-05-09 19:19:56 UTC
From:
To:
Hi,

Thanks for your report! I think we should have alredy enough
information here to forward it upstream. But before doing so, can you
please test as well the most recent version (7.0.4-1) to see if you
still can reproduce.

Regards,
Salvatore

#1135354#17
Date:
2026-05-10 14:39:43 UTC
From:
To:
Hi,

Thanks a lot for paying attention to this, I'll try to reproduce and report
the most recent situation on 7.0.4-1 ASAP.

#1135354#22
Date:
2026-05-12 12:28:39 UTC
From:
To:
Hi maintainers,

I tested kernel 7.0.4-1 (uname -r tells it as "7.0.4+deb14-amd64).

It seems like the issue is already fixed in this version of kernel.

The dmesg shows the codec auto-probing completes cleanly at ~6.72s, and all
devices are registered by ~6.73s - well before userspace audio services
start.

The root cause (timing race) appears to have been resolved.

Please close this bug as fixed now.

By the way, thanks a lot for your attention to this issue and efforts to
bring Debian to us the users.

Thanks,
Yu Rui