Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-1673-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240206110816.74995-1-verdre@v0yd.nl> <170732222621.9598.18285805408891036019.git-patchwork-notify@kernel.org>
In-Reply-To: <170732222621.9598.18285805408891036019.git-patchwork-notify@kernel.org>
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date: Wed, 7 Feb 2024 11:33:59 -0500
Message-ID: <CABBYNZLtbEnU3wfnym0P8gamh1_5GcUHKvAnxh4GpcBC3G56uQ@mail.gmail.com>
Subject: Re: [PATCH v4 0/2] Bluetooth: Improve retrying of connection attempts
To: patchwork-bot+bluetooth@kernel.org
Cc: marcel@holtmann.org, johan.hedberg@gmail.com, 
	linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org, 
	netdev@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jonas,

On Wed, Feb 7, 2024 at 11:10=E2=80=AFAM <patchwork-bot+bluetooth@kernel.org=
> wrote:
>
> Hello:
>
> This series was applied to bluetooth/bluetooth-next.git (master)
> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
>
> On Tue,  6 Feb 2024 12:08:12 +0100 you wrote:
> > Since commit 4c67bc74f016 ("[Bluetooth] Support concurrent connect
> > requests"), the kernel supports trying to connect again in case the
> > bluetooth card is busy and fails to connect.
> >
> > The logic that should handle this became a bit spotty over time, and al=
so
> > cards these days appear to fail with more errors than just "Command
> > Disallowed".
> >
> > [...]
>
> Here is the summary with links:
>   - [v4,1/2] Bluetooth: hci_conn: Only do ACL connections sequentially
>     https://git.kernel.org/bluetooth/bluetooth-next/c/456561ba8e49
>   - [v4,2/2] Bluetooth: Remove pending ACL connection attempts
>     https://git.kernel.org/bluetooth/bluetooth-next/c/8e14d581d125
>
> You are awesome, thank you!
> --
> Deet-doot-dot, I am a bot.
> https://korg.docs.kernel.org/patchwork/pwbot.html

Something is not quite right with these changes:

L2CAP BR/EDR Client - Timeout - test passed
L2CAP BR/EDR Client - Timeout - teardown
Bluetooth: hci0: command 0x0408 tx timeout
  Index Removed callback
    Index: 0x0000
L2CAP BR/EDR Client - Timeout - teardown complete
L2CAP BR/EDR Client - Timeout - done
L2CAP BR/EDR Client - Timeout                        Passed      22.329 sec=
onds

The test seems to be blocked on teardown then the command times out,
0x0408 is HCI_OP_CREATE_CONN_CANCEL so I wonder why it would be timing
out. Anyway the test uses SO_SNDTIMEO to set a timeout at the socket
level but it doesn't seem it is used while creating the connection so
it probably needs to be passed down or something.


--=20
Luiz Augusto von Dentz