linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thorsten Leemhuis <regressions@leemhuis.info>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: "linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	Marcel Holtmann <marcel@holtmann.org>,
	"regressions@lists.linux.dev" <regressions@lists.linux.dev>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Tedd Ho-Jeong An <hj.tedd.an@gmail.com>
Subject: Re: [BUG] BLE device unpairing triggers kernel panic
Date: Mon, 4 Jul 2022 14:11:31 +0200	[thread overview]
Message-ID: <b7b080ff-a5da-a10c-674b-c3bb653f0aeb@leemhuis.info> (raw)
In-Reply-To: <CABBYNZJQKc9ozReXLeESWY8U648eQytKfGB4WmhZi4M+YOW7jw@mail.gmail.com>

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

On 24.06.22 21:59, Luiz Augusto von Dentz wrote:
> On Fri, Jun 24, 2022 at 5:53 AM Ahmad Fatoum <a.fatoum@pengutronix.de> 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@pengutronix.de> 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@pengutronix.de> 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@pengutronix.de/T/#t

  reply	other threads:[~2022-07-04 12:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-13 14:10 [BUG] BLE device unpairing triggers kernel panic Ahmad Fatoum
2022-05-13 20:14 ` Luiz Augusto von Dentz
2022-05-13 23:52   ` Luiz Augusto von Dentz
2022-05-13 23:57     ` Luiz Augusto von Dentz
2022-05-16 16:37     ` Ahmad Fatoum
2022-06-16 10:38       ` Ahmad Fatoum
2022-06-17 20:48         ` Luiz Augusto von Dentz
2022-06-20 10:06           ` Ahmad Fatoum
2022-06-20 20:18             ` Luiz Augusto von Dentz
2022-06-21  8:32               ` Ahmad Fatoum
2022-06-21 18:52                 ` Luiz Augusto von Dentz
2022-06-24 12:53                   ` Ahmad Fatoum
2022-06-24 19:59                     ` Luiz Augusto von Dentz
2022-07-04 12:11                       ` Thorsten Leemhuis [this message]
2022-07-07  5:45                         ` Ahmad Fatoum
2022-08-17 10:24                           ` Thorsten Leemhuis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b7b080ff-a5da-a10c-674b-c3bb653f0aeb@leemhuis.info \
    --to=regressions@leemhuis.info \
    --cc=a.fatoum@pengutronix.de \
    --cc=hj.tedd.an@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=regressions@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).