Re: [BUG] Bluetooth: WCN6855 10ab:9309 stops reporting ISO TX completions during BAP LC3

Thanks, that makes sense.

CC'ing Bartosz since this looks like it may be related to the Qualcomm 
Bluetooth driver or firmware.

A few extra details:

  * Bluetooth is connected over USB: 10ab:9309
  * ROM version: 0x130201
  * Firmware:
      o qca/rampatch_usb_00130201.bin
      o qca/nvm_usb_00130201_gf.bin
  * I checked both files against current upstream linux-firmware and
    they match exactly.

SHA-256:

rampatch_usb_00130201.bin
10bb07a4c8d0e38d4fae9f6f5c10c51b54308fefe58d5587e3a3bb14b8fdb3c0

nvm_usb_00130201_gf.bin
59052bce0444fc35028aea8a854d31adb738a0ffd6ec5fbd4df54e6cf5475af8

The issue is still the same: four HCI ISO packets are sent, but no 
completion events are returned for the CIS, so transmission stops once 
the available buffers are used up.

Bartosz, does this look like a Qualcomm driver/firmware issue, or is 
there someone at Qualcomm I should CC for this?

Regards,
Jonas


Am 11.08.26 um 04:58 schrieb Luiz Augusto von Dentz:
> Hi Jonas,
>
> On Mon, Aug 10, 2026 at 6:22 PM Jonas Zunker <[email protected]> wrote:
>> Hello,
>>
>>     I am seeing a Bluetooth LE Audio/BAP failure with a Qualcomm WCN6855
>>     controller and Sony WH-1000XM6 headphones.
>>
>>     BAP negotiation succeeds and the audio profile appears active, but no
>> sound is
>>     heard. The attached btmon capture indicates that the controller stops
>> returning
>>     HCI ISO transmit completions.
>>
>>     Observed sequence
>>     =================
>>
>>     1. The sink and source ASE QoS configurations are accepted.
>>     2. The Enable operation succeeds for both ASEs.
>>     3. The connected isochronous stream is established successfully as CIS
>>        handle 4.
>>     4. Both host-to-controller and controller-to-host ISO data paths are
>> configured
>>        successfully.
>>     5. The sink and source ASEs both reach the Streaming state.
>>     6. The host submits four 120-byte HCI ISO packets on CIS handle 4.
>>     7. No Number Of Completed Packets event is received for CIS handle 4.
>>     8. Number Of Completed Packets events for ACL handle 3 continue normally.
>>     9. No further ISO audio packets are submitted, although application
>> playback
>>        remains active.
>>
>>     The final ISO packets in the attached capture are:
>>
>>         < LE-CIS: Handle 4 SN 0 ... slen 120
>>         < LE-CIS: Handle 4 SN 1 ... slen 120
>>         < LE-CIS: Handle 4 SN 2 ... slen 120
>>         < LE-CIS: Handle 4 SN 3 ... slen 120
>>
>>     There is no completion event for CIS handle 4 after these packets.
>>
>>     This appears to exhaust the four initial HCI ISO transmit credits.
>> The host
>>     cannot submit more audio because the controller does not replenish those
>>     credits.
>>
>>     PipeWire/WirePlumber also reports:
>>
>>         spa.bluez5.iso: Missing completion reports for packet ...
>>         Bluetooth adapter firmware bug?
>>
>>     After approximately 20 seconds, the kernel reports:
>>
>>         Bluetooth: hci0: link tx timeout
>>         Bluetooth: hci0: killing stalled connection <headset-address>
>>
>>     I am not attaching my complete system journal. The kernel messages
>> above were
>>     selected manually from the local logs.
>>
>>     Hardware
>>     ========
>>
>>     - Bluetooth controller: Qualcomm WCN6855
>>     - USB ID: 10ab:9309
>>     - Kernel drivers: btusb / btqca
>>     - Firmware patch file: qca/rampatch_usb_00130201.bin
>>     - NVM file: qca/nvm_usb_00130201_gf.bin
>>     - QCA ROM version: 0x130201
>>     - QCA patch build: 0x994d
>>     - QCA firmware build: 0x38e6
>>     - Headset: Sony WH-1000XM6
>>
>>     Software
>>     ========
>>
>>     - Distribution: Fedora 44
>>     - Kernel: 7.1.7-200.fc44.x86_64
>>     - Fedora BlueZ: bluez-5.87-3.fc44.x86_64
>>     - Upstream BlueZ: latest master, locally built
>>     - PipeWire: 1.6.8-1.fc44.x86_64
>>     - WirePlumber: 0.5.14-1.fc44.x86_64
>>     - linux-firmware: 20260622-1.fc44.noarch
>>
>>     The issue reproduces with both:
>>
>>     1. The unmodified Fedora bluez-5.87-3.fc44 package.
>>     2. A locally built version of the latest upstream BlueZ master tree.
>>
>>     The same four-packet ISO TX stall occurs with both versions.
>> Therefore, the
>>     failure does not appear to depend on my local BlueZ diagnostic changes.
>>
>>     The attached capture was recorded while using the upstream build. I
>> separately
>>     reproduced the same behavior with the unmodified Fedora BlueZ package.
>>
>>     Reproduction
>>     ============
>>
>>     1. Run either the Fedora-provided BlueZ daemon or an unmodified build
>> of the
>>        latest upstream BlueZ master.
>>     2. Pair and connect the Sony WH-1000XM6 over LE.
>>     3. Select the XM6 BAP/LC3 audio profile in GNOME sound settings.
>>     4. Start audio playback.
>>     5. BAP setup succeeds and both ASEs reach Streaming.
>>     6. No sound is heard.
>>     7. btmon records four outgoing ISO packets on CIS handle 4.
>>     8. No completion reports for CIS handle 4 follow.
>>     9. The connection eventually hits the kernel TX timeout.
>>
>>     Completely removing and pairing the headset again does not change the
>> result.
>>
>>     Expected result
>>     ===============
>>
>>     The controller should report completion of transmitted ISO packets
>> for CIS
>>     handle 4, allowing the host to replenish its ISO transmit credits and
>> continue
>>     sending LC3 audio.
>>
>>     Actual result
>>     =============
>>
>>     The controller accepts four ISO packets but provides no completion
>> reports for
>>     CIS handle 4. Audio transmission then stops, and the connection
>> eventually
>>     times out.
>>
>>     Regression status
>>     =================
>>
>>     I initially observed working LE Audio with the Fedora-provided stack,
>> but I have
>>     not yet isolated a specific kernel or firmware version where the behavior
>>     changed. I am therefore not marking this as a confirmed regression.
>>
>>     LLM disclosure
>>     ==============
>>
>>     I used an LLM assistant to help analyze the btmon capture and draft
>> this report.
>>     The capture and reproduction results come from my own system. I
>> reviewed the
>>     technical claims and am responsible for the submitted report.
>>
>>     Please let me know if a longer btmon capture, controller information,
>> or a
>>     comparison against another kernel would be useful.
>>
>>     Regards,
>>     Jonas
> Sounds like a firmware bug, I wouldn't be surprised if the firmware
> doesn't expect the audio to be transmitted over HCI. Anyway, without
> the Number of Completed Packets events the stack stops transmitting as
> soon as it detects the buffer is exhausted, so the packets are
> considered in flight and never complete. You may want to try to
> contact the driver author or the person who submitted the firmware to
> linux-firmware, perhaps Qualcomm will need to provide a different
> firmware for Linux, one that does allow the audio to be transmitted
> over HCI.
>