Hi On 01/03/2022 18:34, Luiz Augusto von Dentz wrote: > Hi Chris, > > On Tue, Mar 1, 2022 at 1:26 AM Chris Clayton <chris2553@xxxxxxxxxxxxxx> wrote: >> >> Hi Luiz, >> >> I guess you are hoping for PEBKAC :-) >> >> On 28/02/2022 21:20, Luiz Augusto von Dentz wrote: >>> Hi Chris, >>> >>> On Mon, Feb 28, 2022 at 1:02 PM Chris Clayton <chris2553@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxx/ >>>>> >>>>> >>>> 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? >>> >> >> Until I got your patch yesterday, I was using a clone of >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git which I update frequently and have been doing so for as >> long as I can remember. Just in case there was a hidden flaw in that tree, I took a new clone yesterday, (so yes, the >> patch was tested on top of rc6) copied over the .config file and applied the patch. Then I built and installed the >> kernel, updated grub, powered off the laptop and booted into the new kernel. Once the laptop had booted and logged in to >> my LXQt desktop, I powered on my headphones and a connection was establisehed almost straight away. I powered the >> headphones off and the disconnection worked fine. >> >> Knowing that the problem crops up intermittently, I then rebooted the laptop. When the boot was complete, I then powered >> on my bluetooth headphones an waited for them to connect to the laptop. After about 20 seconds, a connection had not >> been established. I powered off the headphones, used modprobe to unload and then reload the btusb module. When I powered >> on the headphones, a connectiin was established within 2 or 3 seconds. >> >> I've booted this laptop countless times over the last few days. Doing the bisect, I didn't mark a commit as good until I >> had done five boots and been able to connect my headphones on each boot. What I can say from that work is that two >> consecutive boots into a working kernel are very rare. I can't remeber an occasion when it took more than two boots to >> establish that a kernel was bad. > > Do commands such as bluetoothctl power on or scan on works? You're taking about systemd things here but as I said last week, I don't use systemd. I use sysvinit and an associated set of boot scripts. Try > running bluetoothd -dn from a shell (disable bluetooth.service), also > are there any settings changed in main.conf? > OK, I'll try that later, It might be tomorrow because I'm busy with other stuff at the moment. Chris >
