Hi Luiz, ti, 2025-03-04 kello 11:38 -0500, Luiz Augusto von Dentz kirjoitti: [clip] > > Looks like this is working when internally, so I wonder what is going > on if you don't receive NOCP on Intel controllers, that said perhaps > we need some way to detect if NOCP is not being generated, perhaps via > timer, then disable HCI_SCO_FLOWCTL, the issue is this perhaps could > cause hiccups at the start of the stream so perhaps we could do the > opposite and always start without setting HCI_SCO_FLOWCTL and only if > NOCP is generated then set HCI_SCO_FLOWCTL which can then be > persisted, thoughts? That's weird. The full btmon dumps are here: https://gitlab.freedesktop.org/pvir/repros/-/raw/main/2025-03-sco-flowctl/sco-flowctl-intel-ax210.txt https://gitlab.freedesktop.org/pvir/repros/-/raw/main/2025-03-sco-flowctl/sco-flowctl-rtl8761bu.txt with Intel firmware [ 5.749140] Bluetooth: hci0: Firmware timestamp 2024.33 buildtype 1 build 81755 [ 5.749146] Bluetooth: hci0: Firmware SHA1: 0xd028ffe4 [ 5.792830] Bluetooth: hci0: Found device firmware: intel/ibt-0041-0041.sfi [ 5.792868] Bluetooth: hci0: Boot Address: 0x100800 [ 5.792870] Bluetooth: hci0: Firmware Version: 91-33.24 [ 5.792872] Bluetooth: hci0: Firmware already loaded [ 5.800638] Bluetooth: hci0: Fseq status: Success (0x00) [ 5.800644] Bluetooth: hci0: Fseq executed: 00.00.02.41 [ 5.800647] Bluetooth: hci0: Fseq BT Top: 00.00.02.41 I checked now again with v4 of the patch, and result was the same: no NOCP, so it writes SCO max packet packets and then stops. This was in KVM virtual machine on Linux with USB redirection, but I don't think that should matter as everything else works in this setup. Enabling flow control only after observing NOCP for SCO handle sounds safer. This probably needs timer, since if you write more than max SCO buffers initially, I guess it's not guaranteed you get flow control messages for each of them. -- Pauli Virtanen
