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

From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: Chris Clayton <chris2553@googlemail.com>
Cc: Chris Murphy <lists@colorremedies.com>,
	Bluetooth <linux-bluetooth@vger.kernel.org>,
	 regressions@lists.linux.dev
Subject: Re: bug kernel 5.17, qualcom and intel adapters, unable to reliably connect to bluetooth devices
Date: Mon, 28 Feb 2022 13:20:20 -0800	[thread overview]
Message-ID: <CABBYNZ+2Dg+AdnJqpR=wS0juektNapwHcPHBWdZyvSGFT1dVLQ@mail.gmail.com> (raw)
In-Reply-To: <6b17bdb5-dddb-e7c7-86f6-2240c6523a81@googlemail.com>

Hi Chris,

On Mon, Feb 28, 2022 at 1:02 PM Chris Clayton <chris2553@googlemail.com> wrote:
>
> 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.

Can you tell us exactly what steps you are using? Are you applying on
top of what, rc6?

-- 
Luiz Augusto von Dentz