Hi, On 04.07.22 14:11, Thorsten Leemhuis wrote: > Hi, this is your Linux kernel regression tracker. Top-posting for once, > to make this easily accessible to everyone. > > Looks like the discussions to fix this regression got stuck. What can be > done to get thing rolling again? Or has progress been made and I just > missed it? Ciao, Thorsten No progress has been made as far as I am aware. I am reverting the commit introducing the regression on my systems and haven't yet had the time to debug this further to help find an alternative solution. Cheers, Ahmad > > On 24.06.22 21:59, Luiz Augusto von Dentz wrote: >> On Fri, Jun 24, 2022 at 5:53 AM Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: >>> On 21.06.22 20:52, Luiz Augusto von Dentz wrote: >>>> On Tue, Jun 21, 2022 at 1:32 AM Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: >>>>> On 20.06.22 22:18, Luiz Augusto von Dentz wrote: >>>>>> On Mon, Jun 20, 2022 at 3:06 AM Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: >>>>>>> Disconnect of connection #1 being processed after new connection #2 >>>>>>> concluded sounds wrong. Would I be able to reconnect >>>>>>> afterwards or would all connections, but the first, be directly >>>>>>> disconnected...? >>>>>> >>>>>> That depends on the order you have queued the commands, it will be >>>>>> processed in the exact order it is received, that why I said it is >>>>>> single queue design, and it is done like that to prevent messing up >>>>>> with states since we know the exact order the commands will be sent. >>>>>> >>>>>>>> otherwise we need a >>>>>>>> different queue to handle command that abort/cancel other already in >>>>>>>> the queue. >>>>>>> >>>>>>> Is the revert an acceptable interim solution or are there issues >>>>>>> I am missing? >>>>>> >>>>>> Afaik there were problem with concurrent connections request, so what >>>>>> would really help us here is to have some tests to emulate this >>>>>> scenario with our CI, in the meantime please check if the following >>>>>> fixes your problem: >>>>>> >>>>>> https://gist.github.com/Vudentz/b4fff292c7f4ad55ca3299fd5ab797ae >>>>> >>>>> Doesn't help unfortunately. First pairing works as before. >>>>> Second still fails: >>>>> >>>>> Bluetooth: hci0: Opcode 0x200d failed: -110 >>>>> Bluetooth: hci0: request failed to create LE connection: err -110 >>>> >>>> Can we try to add a test in mgmt-tester to reproduce the error above? >>> >>> I am not familiar with mgmt-tester. What information do you >>> need to reproduce? In the meantime, can we revert the commit? >>> I understand that this may break other uses, but I believe >>> previously working stuff should have precedence.. >> >> Have a looks at: >> >> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/test-runner.txt >> >> And then run with: >> >> sudo tools/test-runner -k <pathyto/bzImage> -- tools/mgmt-tester >> >> Btw, can we have the exact steps to reproduce it using bluetoothctl if possible? >> >>> Cheers, >>> Ahmad >>> >>>> >>>>> Cheers, >>>>> Ahmad >>>>> >>>>>> >>>>>>> Cheers, >>>>>>> Ahmad >>>>>>> >>>>>>>> >>>>>>>>> We've been deploying the revert for a while now and I just posted >>>>>>>>> it to the mailing list[1]. There have been other reports >>>>>>>>> of this issue with different hardware too and fixing sent_cmd >>>>>>>>> would likely be too complicated/time intensive for me. >>>>>>>>> >>>>>>>>> I am happy to test future patches that fix this properly though. >>>>>>>>> >>>>>>>>> [1]: https://lore.kernel.org/linux-bluetooth/20220616092418.738877-1-a.fatoum@xxxxxxxxxxxxxx/T/#t > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
