Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a58b7849-540a-53a8-bfc5-6198312a0728@googlemail.com>
Date:   Thu, 24 Feb 2022 08:24:07 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.1
Subject: Re: bug kernel 5.17, qualcom and intel adapters, unable to reliably
 connect to bluetooth devices
Content-Language: en-GB
From:   Chris Clayton <chris2553@googlemail.com>
To:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc:     Chris Murphy <lists@colorremedies.com>,
        Bluetooth <linux-bluetooth@vger.kernel.org>
References: <CAJCQCtSeUtHCgsHXLGrSTWKmyjaQDbDNpP4rb0i+RE+L2FTXSA@mail.gmail.com>
 <CABBYNZKfy-ntFhbx0TStNwFiwxCF4sPVaHS4wDbef0shb=pawg@mail.gmail.com>
 <CAJCQCtRiTQ1BTEHugxhS-zmXFG4qi4WLxsRyZsG9-_Q0isM+7Q@mail.gmail.com>
 <CAJCQCtS35JeABLDBaNpfgxjq+ZJ9rZgwtRnSYLNm8tMwtdYGMw@mail.gmail.com>
 <CABBYNZKTSe83iP4tm36we4cpAbeGUbEw9frZD1wCM9yo1zry5w@mail.gmail.com>
 <CAJCQCtTpHQe2co3fLNs5csKQchmwH=3YwQOvFnuc2nhjRseVnw@mail.gmail.com>
 <9ad505e1-7b59-7ebf-378b-23a6c0e25802@googlemail.com>
 <CABBYNZ+9tUKgLyUWM5vkMW8vHxYsXv6DEaDWdHt8xTTs6puGQA@mail.gmail.com>
 <aaeb4131-d177-d41e-617b-b0060cd83c92@googlemail.com>
 <CABBYNZLB+8UzhzttMrKbHW_+-A1EsY9iT5Y55VuOOEPuD4kAHQ@mail.gmail.com>
 <b1a4a920-dbba-58be-72b4-2c95b9b79283@googlemail.com>
 <82216882-463a-8976-e6bc-4a8919107a31@googlemail.com>
 <CABBYNZ+mO1gQgfwhemY9cqbi8vNLm_60A9c1vPYT2tH4rhgFww@mail.gmail.com>
 <a35b4b75-bb64-89c8-bacd-d58ed8576272@googlemail.com>
 <2ce6175c-74ec-8469-80a5-374bd1429542@googlemail.com>
In-Reply-To: <2ce6175c-74ec-8469-80a5-374bd1429542@googlemail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hello,

On 24/02/2022 05:59, Chris Clayton wrote:
> 
> 
> On 23/02/2022 22:42, Chris Clayton wrote:
>> Hi.
>>
>> <snip>
>>
>>>
>>> We are starting to suspect this is not a new issue, it just become
>>> easier to reproduce with newer kernels since the mgmt commands are now
>>> handled by a different work/thread which probably takes longer to
>>> respond hitting problems such as:
>>>
>>> https://github.com/bluez/bluez/issues/275#issuecomment-1020608282
>>>
>>> This has been fixed by:
>>>
>>> https://github.com/bluez/bluez/commit/faad125c5505b941f06c54525616e192a6369208
>>> https://github.com/bluez/bluez/commit/5f378404bff6bbfea3f20e36535c494efa5066a5
>>>
>>
>> I cloned bluez, but that FTBFS, so I applied the two patches by hand.
>>

Sorry, the FTBFS was my error - I didn't do the autotools magic properly. More haste, less speed!

So I've now built and tested 5.17-rc5+ (v5.17-rc5-21-g23d04328444a) with bluetoothd built from a fresh clone of the
bluez git tree taken this morning (HEAD is d89af9a). I'm sorry to say that I still get the intermittent failures when
trying to connect my bluetooth devices. By intermittent I mean that if after starting the system from cold, if the first
attempt to connect fails, then subsequent attempts also fail. If, however, the first attempt succeeds, I can disconnect
and connect again as many times as I want. With a 5.16.10 kernel, connecting and disconnecting  works reliably like it
did with vanilla bluez-5.63.

Chris

>> After the first boot, my bluetooth devices connected fine. But after a poweroff and boot, they didn't. Nor did they on
>> the third and fourth boots, so the patches don't seem to be the answer. (They couldn't really be anyway because changes
>> to the kernel have broken user-space which I understand is a big no no unless there is a really compelling reason.)
>>
>> I've gathered some diagnostics today and they are attached. They consist of 6 files containing the output from btmon and
>> dmesg and the log file for the system daemons, which, of course, includes bluetoothd. There are 2 sets of these files -
>> one from a boot that resulted in a system where my devices would not connect and another from a boot where they could
> 
> s/would not connect and another/would connect and another/
> 
>> not connect. You'll note that the btmon log is empty for a failed connection.
>>
>> I also tried a bisection with v5.16 as good and v5.17-rc1 as bad. Unfortunately, I found several steps resulted in a
>> kernel where bluetooth seemed to be substantially borked - to the extent that blueman was non-functional and clicking on
>> the tray icon did not start up the blueman-manager application.
>>
>> I also booted into a 5.16.10 kernel and connecting bluetooth devices worked flawlessly. (This was with the unpatched
>> bluez daemon)
>>
>> Chris
>>> So the timer doesn't start until the request is sent. but obvoiusly
>>> older versions of userspace don't have that fix so they end up
>>> cancelling the loading of LTKs, this would explain why reloading the
>>> daemon would make it work again.