Bug 215576

[TLDR: I'm adding the regression report below to regzbot, the Linux
kernel regression tracking bot; all text you find below is compiled from
a few templates paragraphs you might have encountered already already
from similar mails.]

Hi, this is your Linux kernel regression tracker speaking.

CCing the regression mailing list, as it should be in the loop for all
regressions, as explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

On 07.02.22 19:00, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=215576
> 
>             Bug ID: 215576
>            Summary: HSP/HFP mSBC profile broken with QCA6174
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 5.16.7
>           Hardware: x86-64
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Bluetooth
>           Assignee: linux-bluetooth@vger.kernel.org
>           Reporter: mike@mjones.io
>         Regression: No
> 
> Created attachment 300405 [details]
>   --> https://bugzilla.kernel.org/attachment.cgi?id=300405&action=edit
> dmesg with 5.16.7
> 
> Between v5.15 and v5.16, mSBC via pipewire stopped working with the QCA6174
> adapter.
> 
> Switching to the HSP/HFP profile with mSBC codec in pipewire produces a loud
> buzzing sound, and the microphone does not function. When using PulseAudio
> instead of pipewire, the buzzing is absent but audio input/output also don't
> work.
> 
> Other users are reporting the same issue at [1].
> 
> I ran a git bisect between these two versions and the issue seems to have
> been
> caused by this commit:
> 
> [b2af264ad3af437238c9500aa830ebcafb180e05] Bluetooth: Add support for
> HCI_Enhanced_Setup_Synchronous_Connection command
> 
> [1] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2019

To be sure this issue doesn't fall through the cracks unnoticed, I'm
adding it to regzbot, my Linux kernel regression tracking bot:

#regzbot ^introduced b2af264ad3af437238c9500aa830ebcafb180e05
#regzbot title bluetooth: HSP/HFP mSBC profile broken with QCA6174
#regzbot ignore-activity
#regzbot link https://bugzilla.kernel.org/show_bug.cgi?id=215576

Reminder for developers: when fixing the issue, please add a 'Link:'
tags pointing to the report (the mail quoted above) using
lore.kernel.org/r/, as explained in
'Documentation/process/submitting-patches.rst' and
'Documentation/process/5.Posting.rst'. This allows the bot to connect
the report with any patches posted or committed to fix the issue; this
again allows the bot to show the current status of regressions and
automatically resolve the issue when the fix hits the right tree.

I'm sending this to everyone that got the initial report, to make them
aware of the tracking. I also hope that messages like this motivate
people to directly get at least the regression mailing list and ideally
even regzbot involved when dealing with regressions, as messages like
this wouldn't be needed then.

Don't worry, I'll send further messages wrt to this regression just to
the lists (with a tag in the subject so people can filter them away), if
they are relevant just for regzbot. With a bit of luck no such messages
will be needed anyway.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I'm getting a lot of
reports on my table. I can only look briefly into most of them and lack
knowledge about most of the areas they concern. I thus unfortunately
will sometimes get things wrong or miss something important. I hope
that's not the case here; if you think it is, don't hesitate to tell me
in a public reply, it's in everyone's interest to set the public record
straight.

Same regression on a mediatek mt7921e, so unlikely to be controller specific?
I also confirm that downgrading to 5.15 fixes mSBC.

hey bluetooth maintainers, what the status here? This regression was reported more than ten days ago, it was bisected, and a second person roughly confirms it, nevertheless there wasn't a single reply yet. Is somebody looking into this?

Hi Kiran,

On Fri, Feb 18, 2022 at 6:35 AM <bugzilla-daemon@kernel.org> wrote:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=215576
>
> The Linux kernel's regression tracker (Thorsten Leemhuis)
> (regressions@leemhuis.info) changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |marcel@holtmann.org,
>                    |                            |regressions@leemhuis.info
>
> --- Comment #3 from The Linux kernel's regression tracker (Thorsten Leemhuis)
> (regressions@leemhuis.info) ---
> hey bluetooth maintainers, what the status here? This regression was reported
> more than ten days ago, it was bisected, and a second person roughly confirms
> it, nevertheless there wasn't a single reply yet. Is somebody looking into
> this?
>
> --
> You may reply to this email to add a comment.
>
> You are receiving this mail because:
> You are the assignee for the bug.

Looks like a regression introduced by:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=b2af264ad3af437238c9500aa830ebcafb180e05

It seems BT_VOICE sets BT_CODEC_TRANSPARENT when perhaps should be
setting BT_CODEC_MSBC:

diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 8eabf41b2993..b35c772efc7e 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -879,15 +879,9 @@ static int sco_sock_setsockopt(struct socket
*sock, int level, int optname,
                }

                sco_pi(sk)->setting = voice.setting;
-               hdev = hci_get_route(&sco_pi(sk)->dst, &sco_pi(sk)->src,
-                                    BDADDR_BREDR);
-               if (!hdev) {
-                       err = -EBADFD;
-                       break;
-               }
-               if (enhanced_sco_capable(hdev) &&
-                   voice.setting == BT_VOICE_TRANSPARENT)
-                       sco_pi(sk)->codec.id = BT_CODEC_TRANSPARENT;
+               if (voice.setting == BT_VOICE_TRANSPARENT)
+                       sco_pi(sk)->codec.id = BT_CODEC_MSBC;
+
                hci_dev_put(hdev);
                break;

I tried applying this patch, even though removing the error checking didn't look right to me. Indeed, after, when trying this, it results in BUG: kernel NULL pointer dereference, with the stack directly located here:

Feb 26 15:21:16 kernel:  sco_sock_setsockopt+0x110/0x530 [bluetooth]

Changing just codec.id = BT_CODEC_MSBC doesn't work either (results in a brief noise on the headset).

Commit b2af264ad3af437238c9500aa830ebcafb180e05 doesn't revert cleanly
anymore. Looking at the code however, it's obvious that just setting
BT_CODEC_MSBC can't work, since hci_enhanced_setup_sync_conn itself
only handles TRANSPARENT (which looks like it's already mSBC underneath)
and CVSD.

However I tried to brutally disable enhanced synchronous connection
support, which is what the commit adds, by doing:

> diff -rud linux-5.16.11.Orig/include/net/bluetooth/hci_core.h
> linux-5.16.11/include/net/bluetooth/hci_core.h
> --- linux-5.16.11.Orig/include/net/bluetooth/hci_core.h 2022-02-23
> 12:06:08.000000000 +0100
> +++ linux-5.16.11/include/net/bluetooth/hci_core.h      2022-02-26
> 16:00:44.896727458 +0100
> @@ -1465,7 +1465,8 @@
>  #define use_ll_privacy(dev) ((dev)->le_features[0] & HCI_LE_LL_PRIVACY)
> 
>  /* Use enhanced synchronous connection if command is supported */
> -#define enhanced_sco_capable(dev) ((dev)->commands[29] & 0x08)
> +#define enhanced_sco_capable(dev) (false)
> 
>  /* Use ext scanning if set ext scan param and ext scan enable is supported
>  */
>  #define use_ext_scan(dev) (((dev)->commands[37] & 0x20) && \

and this "unbreaks" mSBC even on a current kernel.

I'm not familiar with BT at all, but again doesn't seem to be a controller-specific issue at all.

Thanks for looking into this, Luiz, and thanks wavexx for your experiments! I can confirm the same results on my system: the first patch (codec.id = BT_CODEC_MSBC) doesn't work, but wavexx's workaround to disable enhanced SCO results in fully-functional mSBC.

I've managed to find a laptop with an Intel AX200, and here mSBC works fine on an unpatched v5.16.11 kernel. So this issue doesn't seem to affect all adapters.

If switching back to non-enhanced sco connect is what it takes, then maybe it should be enabled only when userspace has set some codec offload setting at least until someone finds a proper fix. Maybe along these lines: https://patchwork.kernel.org/project/bluetooth/patch/20220227163430.24694-1-pav@iki.fi/

Any consensus at least of what a proper fix would look like? I have to rebuild a new kernel for this laptop and I can help test around @pav's patch if needed.

Is Kiran in the loop?

I no longer have access to an AX20? chipset to make some tests on it sadly.

Maybe we just need to check a controller capabilities flag for E-SCO in addition to the device's own capabilities.

Posted a new series about this:

https://patchwork.kernel.org/project/bluetooth/list/?series=627309

So did the series got accepted/merged, and did it land in linux yet? (patchwork now shows me just an empty page..).

Just checking on the 5.18 trunk I don't see any change besides minor other fixes.

I'm a rookie here but it looks like the fix entered the mainline tree with this merge: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e062cda7d90543ac8c7700fc7c5527d0c0f22ad

The fix itself is this commit and its immediate parents: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d44e1dbda36fff5d7c2586683c4adc0963aef908

So it looks like it will be included in the 5.19 release. Hugely appreciated!

However, not having a functioning bluetooth HSP mode is incredibly inconvenient in the age of Zoom, and there are now three major revisions where this is broken: 5.16, 5.17, and 5.18. Any chance we'll see some backports to get this in people's hands faster?

The regression tracker expressed a similar sentiment here: https://patchwork.kernel.org/project/bluetooth/patch/20220401233826.122544-1-luiz.dentz@gmail.com/#24810088

> Any chance we'll see some backports to get this in people's hands faster?

The maintainers just need to ask the stable to to backport this; note sure, maybe asking them for this on the mailing list might lead to better results.

But even if they don't do that, there is a good chance that this might be backported within the next two weeks

Created attachment 301217 [details]
Add HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN to btmtk to fix mSBC

I'm testing now 5.18.5 (from debian unstable) where this has been backported.

Still broken on mt7921e, mSBM doesn't work.

I see no quirk set there. Adding HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN to btmtk fixes it.

(In reply to wavexx from comment #15)
> Created attachment 301217 [details]
> Add HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN to btmtk to fix mSBC

Thx. FWIW, this might easily get lost here. Would be really good if you could sent this to the bluetooth maintainers, ideally as a proper patch with changelog and everything:


BLUETOOTH DRIVERS
M:	Marcel Holtmann <marcel@holtmann.org>
M:	Johan Hedberg <johan.hedberg@gmail.com>
M:	Luiz Augusto von Dentz <luiz.dentz@gmail.com>
L:	linux-bluetooth@vger.kernel.org
S:	Supported
W:	http://www.bluez.org/
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
F:	drivers/bluetooth/

Well I hope it's not going to get lost _in_ the bug tracker ;)

At the moment I'd be happy if some maintainer simply made the commit. For a one line change I'd rather not start cloning yet another repo...

(In reply to wavexx from comment #17)
> Well I hope it's not going to get lost _in_ the bug tracker ;)

To quote https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html:

Very few subsystems use a bug tracker, and only some of those rely on bugzilla.kernel.org.

> At the moment I'd be happy if some maintainer simply made the commit. For a
> one line change I'd rather not start cloning yet another repo...

With a bit of luck that will work. But if you don't hear anything within the next few days, you really want to send it by mail. A simple mail with a patch like the one you applied here might do the trick with a bit of luck.

I think that I've same problem with followed bluetooth adapter:

Bus 001 Device 005: ID 8087:0026 Intel Corp.

[   41.184754] Bluetooth: hci0: Bootloader revision 0.4 build 0 week 30 2018
[   41.185760] Bluetooth: hci0: Device revision is 2
[   41.185769] Bluetooth: hci0: Secure boot is enabled
[   41.185775] Bluetooth: hci0: OTP lock is enabled
[   41.185780] Bluetooth: hci0: API lock is enabled
[   41.185784] Bluetooth: hci0: Debug lock is disabled
[   41.185789] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[   41.187739] Bluetooth: hci0: Found device firmware: intel/ibt-19-0-4.sfi
[   41.187762] Bluetooth: hci0: Boot Address: 0x24800
[   41.187763] Bluetooth: hci0: Firmware Version: 191-21.21
[   41.884145] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   41.884148] Bluetooth: BNEP filters: protocol multicast
[   41.884150] Bluetooth: BNEP socket layer initialized
[   42.786061] Bluetooth: hci0: Waiting for firmware download to complete
[   42.786699] Bluetooth: hci0: Firmware loaded in 1561482 usecs
[   42.786723] Bluetooth: hci0: Waiting for device to boot
[   42.801703] Bluetooth: hci0: Device booted in 14639 usecs
[   42.801733] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-19-0-4.ddc
[   42.803713] Bluetooth: hci0: Applying Intel DDC parameters completed
[   42.804752] Bluetooth: hci0: Firmware revision 0.0 build 191 week 21 2021
[   42.887147] Bluetooth: RFCOMM TTY layer initialized
[   42.887153] Bluetooth: RFCOMM socket layer initialized
[   42.887156] Bluetooth: RFCOMM ver 1.11


Also running debian 5.18.5 kernel and getting cracking sound recorded from mic.

(In reply to Dmitry Nezhevenko from comment #19)
> I think that I've same problem with followed bluetooth adapter:

See the advice given in Comment 16 (and Comment 18, too) of this bug. In short: best to report this by mail (or a new ticket).