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.
