Hello, On 24/02/2022 05:59, Chris Clayton 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. >> Sorry, the FTBFS was my error - I didn't do the autotools magic properly. More haste, less speed! So I've now built and tested 5.17-rc5+ (v5.17-rc5-21-g23d04328444a) with bluetoothd built from a fresh clone of the bluez git tree taken this morning (HEAD is d89af9a). I'm sorry to say that I still get the intermittent failures when trying to connect my bluetooth devices. By intermittent I mean that if after starting the system from cold, if the first attempt to connect fails, then subsequent attempts also fail. If, however, the first attempt succeeds, I can disconnect and connect again as many times as I want. With a 5.16.10 kernel, connecting and disconnecting works reliably like it did with vanilla bluez-5.63. Chris >> 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.
