Public bug reported:
Hello,
Disclaimer
----------
The investigation was driven using an AI agent, so please bear with me for any
imprecise or incorrect fact, as I'm not knowledgeable in the bluetooth area. It
wrote part of this bug description, and I felt it should be clear enough for
people knowledgeable on the USB stack and its quirks, so it's only very lightly
edited.
Hardware / software
-------------------
Machine : Lenovo ThinkPad Z13 Gen 2 (21JVCTO1WW), AMD Ryzen 7 PRO 7840U
Bluetooth : USB 0489:e0d9 (btusb), MT7922
WLAN (same pkg): PCI 14c3:0616, mt7921e
Controller : HW/SW Version 0x008a008a
Kernel : 7.0.0-28-generic (Ubuntu 24.04.3 LTS, HWE)
BlueZ : 5.72
Peer device : "PORT ON'R 700" BR/EDR headset (HFP + A2DP)
Firmware, BT_RAM_CODE_MT7922_1_1_hdr.bin — reproduced on BOTH:
Build Time 20250523103438 (Ubuntu linux-firmware
20240318.git3b128b60-0ubuntu2.27)
Build Time 20260724143815 (upstream linux-firmware.git, fetched 2026-08-09)
Symptom
-------
During an HFP call the bluetooth connection cuts out for a few seconds (from
human perception),
then the link is re-established by the device.
Frequency is variable, but on the order of a few occurrences per hour
of active HFP use. A2DP-only playback is completely stable and has never once
exhibited this — the fault occurs only when an eSCO link is up.
Per-firmware teardown counts from the same machine and same headset:
fw 20260724 : 12 teardowns (2026-08-09 15:32 .. 2026-08-12 17:36)
fw 20250523 : 21 teardowns (2026-08-09 14:21 .. 15:32, and 08-12 17:36 ..
08-14)
Evidence
--------
HCI capture via dumpcap on the bluetooth-monitor interface. The synchronous
connection is set up with entirely normal parameters:
SYNC-CONN-COMPLETE handle=0x0e00 status=Success type=eSCO
air_mode=3 (Transparent/mSBC)
rx_packet_length=60 tx_packet_length=60
At the failure, both handles are torn down in the same millisecond:
15:39:04.704 DISCONNECT handle=0x0e00 (eSCO) reason=0x08 Connection Timeout
15:39:04.704 DISCONNECT handle=0x0032 (ACL) reason=0x08 Connection Timeout
15:39:07.246 SYNC-CONN-COMPLETE handle=0x0e00 status=Success
(re-established)
SCO packet counts per second around the teardown (offset 0 =
disconnect):
offset sco-rx sco-tx
-30 134 134
-20 133 134
-10 134 133
-5 133 133
-2 133 133
-1 134 133
+0 132 134 <-- disconnect occurs in this second
+1 0 0
+2 59 58 <-- re-establishing
+3 134 133
Inbound eSCO is sustained at ~133 packets/second for the entire 30 seconds
preceding the teardown, including the second in which it occurs. There is no
degradation, no ramp-down, and no loss of inbound traffic beforehand. The link
is
carrying data normally right up to the instant the controller declares it timed
out, and I hear my headset's disconnection announcement.
What this does not appear to be
-------------------------------
- Not RF range or interference: inbound rate is flat at full throughput until
the
teardown; degradation would be visible first.
- Not codec-specific: reproduces with both mSBC (Transparent) and CVSD.
- Not power management: btusb autosuspend disabled (enable_autosuspend=0), and
WLAN power save off.
- Not the firmware revision: reproduces on the May 2025 and July 2026 blobs.
- Not fixable via disable_esco: setting bluetooth.disable_esco=1 prevents any
SCO
link from being established at all with this headset (mic goes dead), rather
than falling back to legacy SCO.
The kernel also logs, at every controller setup:
Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is
advertised, but not supported.
I understand this is an already-applied quirk rather than a live fault, and note
it only in case it is relevant to how the synchronous connection is configured.
After each teardown the kernel logs the following, which I believe are
downstream
consequences of the link disappearing rather than causes — the controller
flushing
buffered data for handles the host has already torn down:
Bluetooth: hci0: SCO packet for unknown connection handle 3584
Bluetooth: hci0: ACL packet for unknown connection handle 3837
Bluetooth: hci0: corrupted SCO packet
Over one 2-day window these appeared 2 times against 13 teardowns, so they do
not
accompany every event.
While investigating this, I made a few bluetooth captures (dumpcap) that
allowed this observation. I've joined the one used by my agent to assess eSCO
teardowns.
Secondary note: btmon crash
---------------------------
Unrelated to the above, but encountered while gathering it: btmon from BlueZ
5.72
aborts while writing a capture from this controller —
*** buffer overflow detected ***: terminated
I worked around it by capturing with dumpcap instead, which writes the stream
without decoding. Happy to file this separately if it is of interest.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: linux-firmware 20240318.git3b128b60-0ubuntu2.27
ProcVersionSignature: Ubuntu 7.0.0-28.28~24.04.1-generic 7.0.12
Uname: Linux 7.0.0-28-generic x86_64
ApportVersion: 2.28.1-0ubuntu3.8
Architecture: amd64
CasperMD5CheckResult: pass
Date: Fri Aug 14 19:10:39 2026
Dependencies: firmware-sof-signed 2023.12.1-1ubuntu1.10
InstallationDate: Installed on 2024-08-06 (738 days ago)
InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Release amd64 (20240424)
MachineType: LENOVO 21JVCTO1WW
ProcEnviron:
LANG=en_US.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm
XDG_RUNTIME_DIR=<set>
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic
root=UUID=f4e67c2e-9a61-45a1-b496-cb9112dba222 ro quiet splash vt.handoff=7
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No
PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
linux-restricted-modules-7.0.0-28-generic N/A
linux-backports-modules-7.0.0-28-generic N/A
linux-firmware 20240318.git3b128b60-0ubuntu2.27
SourcePackage: linux-firmware
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/27/2023
dmi.bios.release: 1.14
dmi.bios.vendor: LENOVO
dmi.bios.version: N41ET37W (1.14 )
dmi.board.asset.tag: Not Available
dmi.board.name: 21JVCTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: SDK0T76530 WIN
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.ec.firmware.release: 1.13
dmi.modalias:
dmi:bvnLENOVO:bvrN41ET37W(1.14):bd11/27/2023:br1.14:efr1.13:svnLENOVO:pn21JVCTO1WW:pvrThinkPadZ13Gen2:rvnLENOVO:rn21JVCTO1WW:rvrSDK0T76530WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21JV_BU_Think_FM_ThinkPadZ13Gen2:pfaThinkPadZ13Gen2:
dmi.product.family: ThinkPad Z13 Gen 2
dmi.product.name: 21JVCTO1WW
dmi.product.sku: LENOVO_MT_21JV_BU_Think_FM_ThinkPad Z13 Gen 2
dmi.product.version: ThinkPad Z13 Gen 2
dmi.sys.vendor: LENOVO
** Affects: linux-firmware (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug noble wayland-session
** Attachment added: "bluetooth capture of a period including the spurious
teardown"
https://bugs.launchpad.net/bugs/2163514/+attachment/5992204/+files/hci-20260813-135117_00009_20260813153335.pcapng
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2163514
Title:
MT7922 (0489:e0d9): spurious "Connection Timeout" teardown of healthy
eSCO+ACL links during HFP calls
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/2163514/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
