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: <2ce6175c-74ec-8469-80a5-374bd1429542@googlemail.com>
Date:   Thu, 24 Feb 2022 05:59:50 +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>
 <CAJCQCtRYKbTQ16eUq2qODZ=dE=HB6pZpLNswdqMbiWw+DBE9KQ@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>
In-Reply-To: <a35b4b75-bb64-89c8-bacd-d58ed8576272@googlemail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk


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.
> 
> 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.