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

[Luiz Augusto von Dentz <luiz.dentz@gmail.com>]

Hi Chris,

On Thu, Feb 24, 2022 at 2:08 AM Chris Clayton <chris2553@googlemail.com> wrote:
>
> Hi Luiz,
>
> On 24/02/2022 08:16, Luiz Augusto von Dentz wrote:
> > Hi Chris,
> >
> > On Wed, Feb 23, 2022 at 9:59 PM Chris Clayton <chris2553@googlemail.com> 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.
> >>>
> >>> 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.
> >
> > Running with 5.17.0-0.rc5.102.fc37.x86_64 there doesn't seem to be any
> > problems, well apart from LE device with Privacy/RPA:
> >
> > https://gist.github.com/Vudentz/5792f4989198c7f2994af2e31eb973af
> >
> > Ive tried suspend/resume a couple of times just to see if there is
> > something odd going own, anyway I'm running with the latest userspace
> > so perhaps I really need some old userspace to reproduce this. There
>
> I don't have an old userspace. I built my system from source about four years ago using the methods from Linux From
> Scratch and Beyond Linux From Scratch. I have been updating the packages since then as and when they are released. In a
> way, you could equate my system to one of the rolling releases. It is very up-to-date but at the same time very stable.
>
> This morning I updated to the latest releases of the 5.15 and 5.16 stable series. I've also built and installed the
> latest in the 5.4 and 5.10 stable series. (All four had new releases yesterday.) Bluetooth works as expected on all 4 of
> those kernels. It has also worked on every kernel released by Linus and every stables series kernel in the last four
> years. I usually start trying out a development kernel when rc3, 4 or 5 is released, depending on time available. If I
> find any problems I report them and provide any diagnostics required and test patches.
>
> Bluetooth is unreliable on my system when I boot 5.17-rc kernels. There is little doubt in my mind that something that
> has changed in 5.17 is at the root of this. Whether it is actually a bug in userspace doesn't change the fact that there
> is a regression because of one or more changes in the kernel. As I said yesterday, my understanding is that such
> regressions are frowned upon.
>
> I'll try another bisection today, but limit its range to changes made in the net/bluetooth directory.

Please record the HCI with btmon, it must be producing something since
it records even the mgmt commands.

> In the meantime I've copied this email to regressions@lists.linux.dev, so they can track this.

Hmm, is that really necessary? 5.17 has not been release tagged yet
and you are already considering it a regression?

> Chris
>
> > might be something with name resolving though, it appears gnome don't
> > show devices if they don't have a proper name (that is not their
> > address) so perhaps that gives the impression there is nothing going
> > on when in fact that all normal, well apart from the fact that names
> > takes way too long to be resolved.
> >
> >>> 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.
> >
> >
> >



-- 
Luiz Augusto von Dentz