Hi Chris, On Thu, Feb 24, 2022 at 2:08 AM Chris Clayton <chris2553@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx, 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
