On 07.07.22 07:45, Ahmad Fatoum wrote: > 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. Just wondering: still no progress I assume? Anyway: I'm putting it on the backburner to get it out of the spot-light, as this doesn't look urgent and things seems to progress very slowly. #regzbot backburner: debuging is slow this further Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight. >> 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 >> > >
