From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [85.220.165.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0258A7C for ; Thu, 7 Jul 2022 05:45:31 +0000 (UTC) Received: from ptz.office.stw.pengutronix.de ([2a0a:edc0:0:900:1d::77] helo=[127.0.0.1]) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1o9KKG-0001Ic-Dn; Thu, 07 Jul 2022 07:45:20 +0200 Message-ID: <577c7140-a30c-ca06-a81e-c791e44b1321@pengutronix.de> Date: Thu, 7 Jul 2022 07:45:16 +0200 Precedence: bulk X-Mailing-List: regressions@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [BUG] BLE device unpairing triggers kernel panic Content-Language: en-US To: Thorsten Leemhuis , Luiz Augusto von Dentz Cc: "linux-bluetooth@vger.kernel.org" , Marcel Holtmann , "regressions@lists.linux.dev" , Pengutronix Kernel Team , Tedd Ho-Jeong An References: <8d5c4724-d511-39b1-21d7-116c91cada45@pengutronix.de> <1d1b76cf-df6f-3935-5cd2-c45ea78f2c33@pengutronix.de> <1a5ec80d-690f-285c-3da8-ccdaf5516d85@pengutronix.de> From: Ahmad Fatoum In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2a0a:edc0:0:900:1d::77 X-SA-Exim-Mail-From: a.fatoum@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: regressions@lists.linux.dev 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 wrote: >>> On 21.06.22 20:52, Luiz Augusto von Dentz wrote: >>>> On Tue, Jun 21, 2022 at 1:32 AM Ahmad Fatoum wrote: >>>>> On 20.06.22 22:18, Luiz Augusto von Dentz wrote: >>>>>> On Mon, Jun 20, 2022 at 3:06 AM Ahmad Fatoum 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 -- 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@pengutronix.de/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 |