Re: bug kernel 5.17, qualcom and intel adapters, unable to reliably connect to bluetooth devices

[Chris Clayton <chris2553@googlemail.com>]

Hi Luiz,

On 28/02/2022 19:34, Luiz Augusto von Dentz wrote:
> Hi Chris,
> 
> On Sat, Feb 26, 2022 at 12:04 AM Chris Clayton <chris2553@googlemail.com> wrote:
>>
>> Hi,
>>
>> On 24/02/2022 15:16, Luiz Augusto von Dentz wrote:
>>>> I'll try another bisection today, but limit its range to changes made in the net/bluetooth directory.
>>
>> That  bisection has proved very difficult because the bluetooth "service" in kernels at some steps of the bisection were
>> completely borked to the extent that blueman's device-manager application wouldn't start and emitted the messages:
>>
>> blueman-manager 12.00.37 ERROR    Manager:137 on_dbus_name_appeared: Default adapter not found, trying first available.
>> blueman-manager 12.00.37 ERROR    Manager:141 on_dbus_name_appeared: No adapter(s) found, exiting
>>
>> Obviously, I don't know whether the problem I am trying to pinpoint is hiding behind this more fundamental problem with
>> the bluetooth "service", so being unable to say whether that kernel was good or bad, I had to skip. There seems to be a
>> batch of commits that mean that, whilst the kernel builds okay, hunting down a bluetooth-related problem is not
>> possible. Eventually and I cursed and gave up. Whatever was causing this breakage has obviously been fixed.
>>
>>> Please record the HCI with btmon, it must be producing something since
>>> it records even the mgmt commands.
>>>
>>
>> Refreshed by a good night's sleep, I started another bisection (between 5.16 and 5.17-rc1) yesterday morning but this
>> time did not limit it to net/bluetooth.  That was going okay until I ran into what I assume is the same batch of borked
>> kernels. I've been more persistent this time but have just had a run of 16 steps in which the bluetooth support in the
>> kernel is broken so badly that testing bluetooth is not possible. I will push on today, but I've suspended that activity
>> to get the hci trace that Luiz has asked for.
>>
>> Using information from the bisect, I built a kernel that had tested as bad (but not borked). The commit is
>> f2b551fad8d8f2ac5e1f810ad595298381e0b0c5. As I've mentioned before, the problem with devices not connecting is
>> intermittent - for a given kernel, sometimes a connection works and other times it doesn't. On the first boot of this
>> kernel, my bluetooth devices could connect, Attached are 4 files related to this - the output from btmon, and the
>> related portions of daemon.log, kern.log and sys.log from /var/log/. Each of the these files is suffixed with ".good".
>>
>> I then powered down the laptop and booted into the same kernel. This time the bluetooth devices could not connect. Four
>> more files are attached for this boot and are suffixed with ".bad". I said in an earlier email that when connection
>> fails, there is no output from btmon, so that log is empty. That's still the case, but I guess that fact itself is a
>> clue to what the problem might be. What I can add, however, is that if, in that same bad kernel, I unload and then
>> reload the btusb module, connections start to work. Maybe that too is a clue. The same unload/load process revives
>> bluetooth on a kernel built after a pull of Linus' latest and greatest this morning.
>>
>> Since I now have a workround, I'm going stop the current bisection that I was doing.  I've done another couple of steps
>> this morning and both produced kernels on which I could not test bluetooth and had to tell git bisect to skip. If
>> however, I can provide any other diagnostics, please let me know.
>>
>> Chris
> 
> Can you try with the following patch:
> 
> https://patchwork.kernel.org/project/bluetooth/patch/20220228173918.524733-1-brian.gix@intel.com/
> 
> 
Sorry, that patch has made no difference. After the first boot my headphones connected okay, but after a power-down and
reboot they would not connect without an unload and reload of the btusb module.

Chris