[PATCH 0/2] Bluetooth: hci_event: Fix connection state issues during suspend/resume

[PATCH 0/2] Bluetooth: hci_event: Fix connection state issues during suspend/resume

[Ludovico de Nittis]

This patch series addresses connection state synchronization issues
between the Bluetooth controller and kernel during suspend/resume cycles.

The problem seems to be visible when using devices that very quickly try
to send multiple reconnect events without waiting enough for the host
to fully resume from suspend.

Fixes the issues reported in https://github.com/bluez/bluez/issues/1226.

Ludovico de Nittis (2):
  Bluetooth: hci_event: Treat UNKNOWN_CONN_ID on disconnect as success
  Bluetooth: hci_event: Mark connection as closed during suspend
    disconnect

 net/bluetooth/hci_event.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

-- 
2.50.1

[PATCH 1/2] Bluetooth: hci_event: Treat UNKNOWN_CONN_ID on disconnect as success

[Ludovico de Nittis]

When the host sends an HCI_OP_DISCONNECT command, the controller may
respond with the status HCI_ERROR_UNKNOWN_CONN_ID. E.g. this can happen
on resume from suspend, if the link was terminated by the remote device
before the event mask was correctly set.

Currently, the hci_cs_disconnect function treats any non-zero status
as a command failure. This can be misleading because the connection is
indeed being terminated and the controller is confirming that is has no
knowledge of that connection handle. Meaning that the initial request of
disconnecting a device should be treated as done.

With this change we allow the function to proceed, following the success
path, which correctly calls `mgmt_device_disconnected` and ensures a
consistent state.

Link: https://github.com/bluez/bluez/issues/1226
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
---
 net/bluetooth/hci_event.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index fe7cdd67a..6c67dfa13 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2703,7 +2703,7 @@ static void hci_cs_disconnect(struct hci_dev *hdev, u8 status)
 	if (!conn)
 		goto unlock;
 
-	if (status) {
+	if (status && status != HCI_ERROR_UNKNOWN_CONN_ID) {
 		mgmt_disconnect_failed(hdev, &conn->dst, conn->type,
 				       conn->dst_type, status);
 
-- 
2.50.1

RE: Bluetooth: hci_event: Fix connection state issues during suspend/resume

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 2750 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=990596

---Test result---

Test Summary:
CheckPatch                    PENDING   0.46 seconds
GitLint                       PENDING   0.28 seconds
SubjectPrefix                 PASS      0.16 seconds
BuildKernel                   PASS      24.51 seconds
CheckAllWarning               PASS      27.11 seconds
CheckSparse                   WARNING   30.90 seconds
BuildKernel32                 PASS      24.41 seconds
TestRunnerSetup               PASS      488.03 seconds
TestRunner_l2cap-tester       PASS      25.51 seconds
TestRunner_iso-tester         PASS      42.81 seconds
TestRunner_bnep-tester        PASS      6.11 seconds
TestRunner_mgmt-tester        FAIL      133.96 seconds
TestRunner_rfcomm-tester      PASS      9.52 seconds
TestRunner_sco-tester         PASS      15.07 seconds
TestRunner_ioctl-tester       PASS      10.20 seconds
TestRunner_mesh-tester        FAIL      11.36 seconds
TestRunner_smp-tester         PASS      8.70 seconds
TestRunner_userchan-tester    PASS      6.32 seconds
IncrementalBuild              PENDING   0.53 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: CheckSparse - WARNING
Desc: Run sparse tool with linux kernel
Output:
net/bluetooth/hci_event.c: note: in included file (through include/net/bluetooth/hci_core.h):net/bluetooth/hci_event.c: note: in included file (through include/net/bluetooth/hci_core.h):
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 490, Passed: 483 (98.6%), Failed: 3, Not Run: 4

Failed Test Cases
Add Ext Advertising - Success 22 (LE -> off, Remove) Failed       0.132 seconds
Set Device ID - Power off and Power on               Failed       0.129 seconds
Set Device ID - SSP off and Power on                 Failed       0.131 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases
Mesh - Send cancel - 1                               Timed out    1.988 seconds
Mesh - Send cancel - 2                               Timed out    1.996 seconds
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth

Re: [PATCH 1/2] Bluetooth: hci_event: Treat UNKNOWN_CONN_ID on disconnect as success

[Paul Menzel]

Dear Ludovico,


Thank you for your patch.

Am 12.08.25 um 16:10 schrieb Ludovico de Nittis:
> When the host sends an HCI_OP_DISCONNECT command, the controller may
> respond with the status HCI_ERROR_UNKNOWN_CONN_ID. E.g. this can happen
> on resume from suspend, if the link was terminated by the remote device
> before the event mask was correctly set.
> 
> Currently, the hci_cs_disconnect function treats any non-zero status
> as a command failure. This can be misleading because the connection is
> indeed being terminated and the controller is confirming that is has no
> knowledge of that connection handle. Meaning that the initial request of
> disconnecting a device should be treated as done.
> 
> With this change we allow the function to proceed, following the success
> path, which correctly calls `mgmt_device_disconnected` and ensures a
> consistent state.

Although part of your issue referenced below, I’d love to see the 
reproducer in the commit message, should you resend.

> Link: https://github.com/bluez/bluez/issues/1226
> Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
> ---
>   net/bluetooth/hci_event.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index fe7cdd67a..6c67dfa13 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -2703,7 +2703,7 @@ static void hci_cs_disconnect(struct hci_dev *hdev, u8 status)
>   	if (!conn)
>   		goto unlock;
>   
> -	if (status) {
> +	if (status && status != HCI_ERROR_UNKNOWN_CONN_ID) {
>   		mgmt_disconnect_failed(hdev, &conn->dst, conn->type,
>   				       conn->dst_type, status);
>   

Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>


Kind regards,

Paul

Re: [PATCH 1/2] Bluetooth: hci_event: Treat UNKNOWN_CONN_ID on disconnect as success

[Ludovico de Nittis]

Hi Paul,

On 8/12/25 5:20 PM, Paul Menzel wrote:
> Dear Ludovico,
>
>
> Thank you for your patch.
>
> Am 12.08.25 um 16:10 schrieb Ludovico de Nittis:
>> When the host sends an HCI_OP_DISCONNECT command, the controller may
>> respond with the status HCI_ERROR_UNKNOWN_CONN_ID. E.g. this can happen
>> on resume from suspend, if the link was terminated by the remote device
>> before the event mask was correctly set.
>>
>> Currently, the hci_cs_disconnect function treats any non-zero status
>> as a command failure. This can be misleading because the connection is
>> indeed being terminated and the controller is confirming that is has no
>> knowledge of that connection handle. Meaning that the initial request of
>> disconnecting a device should be treated as done.
>>
>> With this change we allow the function to proceed, following the success
>> path, which correctly calls `mgmt_device_disconnected` and ensures a
>> consistent state.
>
> Although part of your issue referenced below, I’d love to see the 
> reproducer in the commit message, should you resend.

Sure, in the v2 I added the btmon snippet in the commit message.

>> Link: https://github.com/bluez/bluez/issues/1226
>> Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
>> ---
>>   net/bluetooth/hci_event.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
>> index fe7cdd67a..6c67dfa13 100644
>> --- a/net/bluetooth/hci_event.c
>> +++ b/net/bluetooth/hci_event.c
>> @@ -2703,7 +2703,7 @@ static void hci_cs_disconnect(struct hci_dev 
>> *hdev, u8 status)
>>       if (!conn)
>>           goto unlock;
>>   -    if (status) {
>> +    if (status && status != HCI_ERROR_UNKNOWN_CONN_ID) {
>>           mgmt_disconnect_failed(hdev, &conn->dst, conn->type,
>>                          conn->dst_type, status);
>
> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
>
>
> Kind regards,
>
> Paul

[PATCH 2/2] Bluetooth: hci_event: Mark connection as closed during suspend disconnect

[Ludovico de Nittis]

When suspending, the disconnect command for an active Bluetooth
connection could be issued, but the corresponding
`HCI_EV_DISCONN_COMPLETE` event might not be received before the system
completes the suspend process. This can lead to an inconsistent state.

On resume, the controller may auto-accept reconnections from the same
device (due to suspend event filters), but these new connections are
rejected by the kernel which still has connection objects from before
suspend. Resulting in errors like:
```
kernel: Bluetooth: hci0: ACL packet for unknown connection handle 1
kernel: Bluetooth: hci0: Ignoring HCI_Connection_Complete for existing
connection
```

This is a btmon snippet that shows the issue:
```
< HCI Command: Disconnect (0x01|0x0006) plen 3
        Handle: 1 Address: 78:20:A5:4A:DF:28 (Nintendo Co.,Ltd)
        Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4
      Disconnect (0x01|0x0006) ncmd 2
        Status: Success (0x00)
[...]
// Host suspends with the event filter set for the device
// On resume, the device tries to reconnect with a new handle

> HCI Event: Connect Complete (0x03) plen 11
        Status: Success (0x00)
        Handle: 2
        Address: 78:20:A5:4A:DF:28 (Nintendo Co.,Ltd)

// Kernel ignores this event because there is an existing connection with
// handle 1
```

By explicitly setting the connection state to BT_CLOSED we can ensure a
consistent state, even if we don't receive the disconnect complete event
in time.

Link: https://github.com/bluez/bluez/issues/1226
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
---
 net/bluetooth/hci_event.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 6c67dfa13..81c9fc774 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2718,6 +2718,11 @@ static void hci_cs_disconnect(struct hci_dev *hdev, u8 status)
 		goto done;
 	}
 
+	/* During suspend, mark connection as closed immediately
+	 * since we might not receive HCI_EV_DISCONN_COMPLETE
+	 */
+	conn->state = BT_CLOSED;
+
 	mgmt_conn = test_and_clear_bit(HCI_CONN_MGMT_CONNECTED, &conn->flags);
 
 	if (conn->type == ACL_LINK) {
-- 
2.50.1

Re: [PATCH 2/2] Bluetooth: hci_event: Mark connection as closed during suspend disconnect

[Luiz Augusto von Dentz]

Hi Ludovico,

On Tue, Aug 12, 2025 at 10:26 AM Ludovico de Nittis
<ludovico.denittis@collabora.com> wrote:
>
> When suspending, the disconnect command for an active Bluetooth
> connection could be issued, but the corresponding
> `HCI_EV_DISCONN_COMPLETE` event might not be received before the system
> completes the suspend process. This can lead to an inconsistent state.
>
> On resume, the controller may auto-accept reconnections from the same
> device (due to suspend event filters), but these new connections are
> rejected by the kernel which still has connection objects from before
> suspend. Resulting in errors like:
> ```
> kernel: Bluetooth: hci0: ACL packet for unknown connection handle 1
> kernel: Bluetooth: hci0: Ignoring HCI_Connection_Complete for existing
> connection
> ```
>
> This is a btmon snippet that shows the issue:
> ```
> < HCI Command: Disconnect (0x01|0x0006) plen 3
>         Handle: 1 Address: 78:20:A5:4A:DF:28 (Nintendo Co.,Ltd)
>         Reason: Remote User Terminated Connection (0x13)
> > HCI Event: Command Status (0x0f) plen 4
>       Disconnect (0x01|0x0006) ncmd 2
>         Status: Success (0x00)
> [...]
> // Host suspends with the event filter set for the device
> // On resume, the device tries to reconnect with a new handle
>
> > HCI Event: Connect Complete (0x03) plen 11
>         Status: Success (0x00)
>         Handle: 2
>         Address: 78:20:A5:4A:DF:28 (Nintendo Co.,Ltd)
>
> // Kernel ignores this event because there is an existing connection with
> // handle 1
> ```
>
> By explicitly setting the connection state to BT_CLOSED we can ensure a
> consistent state, even if we don't receive the disconnect complete event
> in time.
>
> Link: https://github.com/bluez/bluez/issues/1226
> Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
> ---
>  net/bluetooth/hci_event.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 6c67dfa13..81c9fc774 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -2718,6 +2718,11 @@ static void hci_cs_disconnect(struct hci_dev *hdev, u8 status)
>                 goto done;
>         }
>
> +       /* During suspend, mark connection as closed immediately
> +        * since we might not receive HCI_EV_DISCONN_COMPLETE
> +        */

Hmm, the comments suggests that this shall be done only for suspend
case though, should we be checking for hdev->suspended?

> +       conn->state = BT_CLOSED;
> +
>         mgmt_conn = test_and_clear_bit(HCI_CONN_MGMT_CONNECTED, &conn->flags);
>
>         if (conn->type == ACL_LINK) {
> --
> 2.50.1
>
>


-- 
Luiz Augusto von Dentz

Re: [PATCH 2/2] Bluetooth: hci_event: Mark connection as closed during suspend disconnect

[Ludovico de Nittis]

Hi Luiz,

On 8/12/25 4:41 PM, Luiz Augusto von Dentz wrote:
> Hi Ludovico,
>
> On Tue, Aug 12, 2025 at 10:26 AM Ludovico de Nittis
> <ludovico.denittis@collabora.com> wrote:
>> When suspending, the disconnect command for an active Bluetooth
>> connection could be issued, but the corresponding
>> `HCI_EV_DISCONN_COMPLETE` event might not be received before the system
>> completes the suspend process. This can lead to an inconsistent state.
>>
>> On resume, the controller may auto-accept reconnections from the same
>> device (due to suspend event filters), but these new connections are
>> rejected by the kernel which still has connection objects from before
>> suspend. Resulting in errors like:
>> ```
>> kernel: Bluetooth: hci0: ACL packet for unknown connection handle 1
>> kernel: Bluetooth: hci0: Ignoring HCI_Connection_Complete for existing
>> connection
>> ```
>>
>> This is a btmon snippet that shows the issue:
>> ```
>> < HCI Command: Disconnect (0x01|0x0006) plen 3
>>          Handle: 1 Address: 78:20:A5:4A:DF:28 (Nintendo Co.,Ltd)
>>          Reason: Remote User Terminated Connection (0x13)
>>> HCI Event: Command Status (0x0f) plen 4
>>        Disconnect (0x01|0x0006) ncmd 2
>>          Status: Success (0x00)
>> [...]
>> // Host suspends with the event filter set for the device
>> // On resume, the device tries to reconnect with a new handle
>>
>>> HCI Event: Connect Complete (0x03) plen 11
>>          Status: Success (0x00)
>>          Handle: 2
>>          Address: 78:20:A5:4A:DF:28 (Nintendo Co.,Ltd)
>>
>> // Kernel ignores this event because there is an existing connection with
>> // handle 1
>> ```
>>
>> By explicitly setting the connection state to BT_CLOSED we can ensure a
>> consistent state, even if we don't receive the disconnect complete event
>> in time.
>>
>> Link: https://github.com/bluez/bluez/issues/1226
>> Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
>> ---
>>   net/bluetooth/hci_event.c | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
>> index 6c67dfa13..81c9fc774 100644
>> --- a/net/bluetooth/hci_event.c
>> +++ b/net/bluetooth/hci_event.c
>> @@ -2718,6 +2718,11 @@ static void hci_cs_disconnect(struct hci_dev *hdev, u8 status)
>>                  goto done;
>>          }
>>
>> +       /* During suspend, mark connection as closed immediately
>> +        * since we might not receive HCI_EV_DISCONN_COMPLETE
>> +        */
> Hmm, the comments suggests that this shall be done only for suspend
> case though, should we be checking for hdev->suspended?

Yes, good point. Initially I didn't do an explicit check because we 
already had:
```
     if (!status && !hdev->suspended)
         return;
[...]
     if (status) {
         [...]
         goto done;
     }
```

But by changing the second `if` to exclude `HCI_ERROR_UNKNOWN_CONN_ID`, 
now there is
one case where it's not implicit the fact that we are in suspend mode.
Let me send a v2 with that change.

>> +       conn->state = BT_CLOSED;
>> +
>>          mgmt_conn = test_and_clear_bit(HCI_CONN_MGMT_CONNECTED, &conn->flags);
>>
>>          if (conn->type == ACL_LINK) {
>> --
>> 2.50.1
>>
>>
>

[PATCH v2 1/2] Bluetooth: hci_event: Treat UNKNOWN_CONN_ID on disconnect as success

[Ludovico de Nittis]

When the host sends an HCI_OP_DISCONNECT command, the controller may
respond with the status HCI_ERROR_UNKNOWN_CONN_ID (0x02). E.g. this can
happen on resume from suspend, if the link was terminated by the remote
device before the event mask was correctly set.

This is a btmon snippet that shows the issue:
```
> ACL Data RX: Handle 3 flags 0x02 dlen 12
      L2CAP: Disconnection Request (0x06) ident 5 len 4
        Destination CID: 65
        Source CID: 72
< ACL Data TX: Handle 3 flags 0x00 dlen 12
      L2CAP: Disconnection Response (0x07) ident 5 len 4
        Destination CID: 65
        Source CID: 72
> ACL Data RX: Handle 3 flags 0x02 dlen 12
      L2CAP: Disconnection Request (0x06) ident 6 len 4
        Destination CID: 64
        Source CID: 71
< ACL Data TX: Handle 3 flags 0x00 dlen 12
      L2CAP: Disconnection Response (0x07) ident 6 len 4
        Destination CID: 64
        Source CID: 71
< HCI Command: Set Event Mask (0x03|0x0001) plen 8
        Mask: 0x3dbff807fffbffff
          Inquiry Complete
          Inquiry Result
          Connection Complete
          Connection Request
          Disconnection Complete
          Authentication Complete
[...]
< HCI Command: Disconnect (0x01|0x0006) plen 3
        Handle: 3 Address: 78:20:A5:4A:DF:28 (Nintendo Co.,Ltd)
        Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4
      Disconnect (0x01|0x0006) ncmd 1
        Status: Unknown Connection Identifier (0x02)
```

Currently, the hci_cs_disconnect function treats any non-zero status
as a command failure. This can be misleading because the connection is
indeed being terminated and the controller is confirming that is has no
knowledge of that connection handle. Meaning that the initial request of
disconnecting a device should be treated as done.

With this change we allow the function to proceed, following the success
path, which correctly calls `mgmt_device_disconnected` and ensures a
consistent state.

Link: https://github.com/bluez/bluez/issues/1226
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
---
 net/bluetooth/hci_event.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index fe7cdd67a..6c67dfa13 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2703,7 +2703,7 @@ static void hci_cs_disconnect(struct hci_dev *hdev, u8 status)
 	if (!conn)
 		goto unlock;
 
-	if (status) {
+	if (status && status != HCI_ERROR_UNKNOWN_CONN_ID) {
 		mgmt_disconnect_failed(hdev, &conn->dst, conn->type,
 				       conn->dst_type, status);
 
-- 
2.50.1

RE: Bluetooth: hci_event: Fix connection state issues during suspend/resume

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 2750 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=990639

---Test result---

Test Summary:
CheckPatch                    PENDING   0.38 seconds
GitLint                       PENDING   0.29 seconds
SubjectPrefix                 PASS      0.19 seconds
BuildKernel                   PASS      25.83 seconds
CheckAllWarning               PASS      28.90 seconds
CheckSparse                   WARNING   32.02 seconds
BuildKernel32                 PASS      24.83 seconds
TestRunnerSetup               PASS      499.81 seconds
TestRunner_l2cap-tester       PASS      25.60 seconds
TestRunner_iso-tester         PASS      42.26 seconds
TestRunner_bnep-tester        PASS      6.07 seconds
TestRunner_mgmt-tester        FAIL      131.91 seconds
TestRunner_rfcomm-tester      PASS      9.51 seconds
TestRunner_sco-tester         PASS      15.02 seconds
TestRunner_ioctl-tester       PASS      10.27 seconds
TestRunner_mesh-tester        FAIL      11.40 seconds
TestRunner_smp-tester         PASS      8.73 seconds
TestRunner_userchan-tester    PASS      6.36 seconds
IncrementalBuild              PENDING   1.10 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: CheckSparse - WARNING
Desc: Run sparse tool with linux kernel
Output:
net/bluetooth/hci_event.c: note: in included file (through include/net/bluetooth/hci_core.h):net/bluetooth/hci_event.c: note: in included file (through include/net/bluetooth/hci_core.h):
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 490, Passed: 483 (98.6%), Failed: 3, Not Run: 4

Failed Test Cases
Add Ext Advertising - Success 22 (LE -> off, Remove) Failed       0.136 seconds
Set Device ID - Power off and Power on               Failed       0.132 seconds
Set Device ID - SSP off and Power on                 Failed       0.124 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases
Mesh - Send cancel - 1                               Timed out    1.871 seconds
Mesh - Send cancel - 2                               Timed out    1.995 seconds
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth