Skip to content

Bluetooth: H4: Cannot receive data anymore after the command bt scan on executed #89879

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
lylezhu2012 opened this issue May 13, 2025 · 0 comments · Fixed by #89917
Closed

Bluetooth: H4: Cannot receive data anymore after the command bt scan on executed #89879

lylezhu2012 opened this issue May 13, 2025 · 0 comments · Fixed by #89917
Assignees
@jhedberg @lylezhu2012 @alwa-nordic
Labels
area: Bluetooth HCI Bluetooth HCI Driver area: Bluetooth bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug

Comments

@lylezhu2012
Copy link
Collaborator

Describe the bug

The H4 cannot received data anymore after the command bt scan on executed if the log <wrn> bt_driver: Failed to allocate, deferring to rx_thread printed.

To Reproduce

Steps to reproduce the behavior:

  1. Build the Bluetooth shell example.
  2. Flash and run the example.
  3. Input command bt init and bt scan on
  4. After the log <wrn> bt_driver: Failed to allocate, deferring to rx_thread printed, no more adv data printed.
  5. And if input bt scan off, the zephyr os will be halt.

Expected behavior

The command bt scan on should work normally.

Impact

Logs and console output

uart:~$ bt init
Bluetooth initialized
[00:00:07.755,000] <wrn> bt_hci_core: Num of Controller's ACL packets != ACL bt_conn_tx contexts (8 != 3)
[00:00:07.755,000] <wrn> bt_hci_core: Num of Controller's ISO packets != ISO bt_conn_tx contexts(16 != 1)
[00:00:07.764,000] <inf> bt_hci_core: HCI transport: H:4
uart:~$ bt scan on
Bluetooth active scan enabled
[DEVICE]: 1B:46:95:7D:37:39 (random), AD evt type 3, RSSI -77  C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: D1:DB:0E:77:74:A0 (random), AD evt type 0, RSSI -89  C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: 5F:8D:02:1C:53:F6 (random), AD evt type 0, RSSI -81  C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: 6D:F4:38:2E:1B:89 (random), AD evt type 0, RSSI -75  C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: D7:FE:F2:98:F4:2F (random), AD evt type 0, RSSI -75  C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: D7:FE:F2:98:F4:2F (random), AD evt type 4, RSSI -75 JBL Tune 520BT-LE C:1 S:1 D:0 SR:1 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: 4F:98:3F:62:02:9C (random), AD evt type 3, RSSI -88  C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: 35:FD:9A:CC:66:B1 (random), AD evt type 3, RSSI -92  C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: 5E:7F:4D:92:BF:CD (random), AD evt type 2, RSSI -80  C:0 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: 76:55:75:E9:F4:09 (random), AD evt type 0, RSSI -75  C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: 76:55:75:E9:F4:09 (random), AD evt type 4, RSSI -75  C:1 S:1 D:0 SR:1 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: 71:F8:2E:EF:9B:1A (random), AD evt type 0, RSSI -87  C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: 71:F8:2E:EF:9B:1A (random), AD evt type 4, RSSI -87  C:1 S:1 D:0 SR:1 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: 62:45:FC:CA:81:8F (random), AD evt type 0, RSSI -62  C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: 62:45:FC:CA:81:8F (random), AD evt type 4, RSSI -62 LE-Bose QC Earbuds C:1 S:1 D:0 SR:1 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: 60:BF:E5:A6:25:12 (random), AD evt type 0, RSSI -89  C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: D7:1C:03:2B:80:1C (random), AD evt type 0, RSSI -90  C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: D7:1C:03:2B:80:1C (random), AD evt type 4, RSSI -91 JBL TUNE520BT-LE C:1 S:1 D:0 SR:1 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[DEVICE]: 60:21:92:9B:63:E8 (random), AD evt type 0, RSSI -90  C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
[00:00:07.764,000] <inf> bt_hci_core: Identity: A0:CD:F3:77:F3:48 (public)
[00:00:07.764,000] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x8300, manufacturer 0x0025
[00:00:07.764,000] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0x1015
[00:00:10.836,000] <wrn> bt_driver: Failed to allocate, deferring to rx_thread
uart:~$
uart:~$ bt scan off
ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:463
        Controller unresponsive, command opcode 0x2042 timeout with err -11
[00:03:09.177,000] <err> os: r0/a1:  0x00000003  r1/a2:  0x00000002  r2/a3:  0x00000001
[00:03:09.177,000] <err> os: r3/a4:  0x00000003 r12/ip:  0x001cddba r14/lr:  0x3000de63
[00:03:09.177,000] <err> os:  xpsr:  0x01000000
[00:03:09.177,000] <err> os: Faulting instruction address (r15/pc): 0x3000de72
[00:03:09.177,000] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:03:09.177,000] <err> os: Current thread: 0x20004af8 (shell_uart)
[00:03:09.208,000] <err> os: Halting system

Environment (please complete the following information):

  • OS: Windows
  • Toolchain Zephyr SDK
  • Commit SHA is 63f2fe9

Additional context

I think rx_thread should be blocked at "buf = k_fifo_get(&h4->rx.fifo, K_FOREVER);" after/when printing ' bt_driver: Failed to allocate, deferring to rx_thread'. This results in it not having a chance to execute the code

zephyr/drivers/bluetooth/hci/h4.c

Lines 245 to 258 in 2a20787

if (h4->rx.have_hdr && !h4->rx.buf) {
h4->rx.buf = get_rx(h4, K_FOREVER);
LOG_DBG("Got rx.buf %p", h4->rx.buf);
if (h4->rx.remaining > net_buf_tailroom(h4->rx.buf)) {
LOG_ERR("Not enough space in buffer");
h4->rx.discard = h4->rx.remaining;
reset_rx(h4);
} else {
copy_hdr(h4);
}
}
/* Let the ISR continue receiving new packets */
uart_irq_rx_enable(cfg->uart);

@lylezhu2012 lylezhu2012 added bug The issue is a bug, or the PR is fixing a bug area: Bluetooth area: Bluetooth HCI Bluetooth HCI Driver labels May 13, 2025
@dkalowsk dkalowsk added the priority: low Low impact/importance bug label May 13, 2025
lylezhu2012 added a commit to nxp-upstream/zephyr that referenced this issue May 14, 2025
@lylezhu2012
Drivers: Bluetooth: H4: Use a semaphore to wake up HCI RX thread
a1c1745 
There is an issue that the buffer cannot be allocated by the function
`read_payload()` in UART ISR context. Then the UART RX will be
disabled. The H4 driver hopes to get the receive buffer in the HCI RX
thread and then open the UART RX again. However, there is a situation
where the HCI RX thread is blocked in getting the received data
buffer. However, since the UARt RX has been disabled, the HCI RX
thread cannot get the received data buffer. Therefore, the RX thread
is always blocked here, causing the Bluetooth host to not work
properly.

Add a semaphore `active_sem` to notify new received data buffer has
been added to H4 RX queue.

Wait for the semaphore `active_sem` instead of H4 RX queue in HCI RX
thread.

Wake up the HCi RX thread when failing to allocate the RX buffer.

Fixes zephyrproject-rtos#89879.

Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
@lylezhu2012 lylezhu2012 mentioned this issue May 14, 2025
Merged
lylezhu2012 added a commit to nxp-upstream/zephyr that referenced this issue May 14, 2025
@lylezhu2012
Drivers: Bluetooth: H4: Use a semaphore to wake up HCI RX thread
81ac116 
There is an issue that the buffer cannot be allocated by the function
`read_payload()` in UART ISR context. Then the UART RX will be
disabled. The H4 driver hopes to get the receive buffer in the HCI RX
thread and then open the UART RX again. However, there is a situation
where the HCI RX thread is blocked in getting the received data
buffer. However, since the UARt RX has been disabled, the HCI RX
thread cannot get the received data buffer. Therefore, the RX thread
is always blocked here, causing the Bluetooth host to not work
properly.

Add a semaphore `rx.ready` to notify new received data buffer has
been added to H4 RX queue.

Wait for the semaphore `rx.ready` instead of H4 RX queue in HCI RX
thread.

Wake up the HCI RX thread when failing to allocate the RX buffer.

Fixes zephyrproject-rtos#89879.

Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
lylezhu2012 added a commit to nxp-upstream/zephyr that referenced this issue May 14, 2025
@lylezhu2012
Drivers: Bluetooth: H4: Use a semaphore to wake up HCI RX thread
c804664 
There is an issue that the buffer cannot be allocated by the function
`read_payload()` in UART ISR context. Then the UART RX will be
disabled. The H4 driver hopes to get the receive buffer in the HCI RX
thread and then open the UART RX again. However, there is a situation
where the HCI RX thread is blocked in getting the received data
buffer. However, since the UARt RX has been disabled, the HCI RX
thread cannot get the received data buffer. Therefore, the RX thread
is always blocked here, causing the Bluetooth host to not work
properly.

Add a semaphore `rx.ready` to notify new received data buffer has
been added to H4 RX queue.

Wait for the semaphore `rx.ready` instead of H4 RX queue in HCI RX
thread.

Wake up the HCI RX thread when failing to allocate the RX buffer.

Fixes zephyrproject-rtos#89879.

Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
kartben pushed a commit that referenced this issue May 26, 2025
@lylezhu2012 @kartben
Drivers: Bluetooth: H4: Use a semaphore to wake up HCI RX thread
71ef6c6 
There is an issue that the buffer cannot be allocated by the function
`read_payload()` in UART ISR context. Then the UART RX will be
disabled. The H4 driver hopes to get the receive buffer in the HCI RX
thread and then open the UART RX again. However, there is a situation
where the HCI RX thread is blocked in getting the received data
buffer. However, since the UARt RX has been disabled, the HCI RX
thread cannot get the received data buffer. Therefore, the RX thread
is always blocked here, causing the Bluetooth host to not work
properly.

Add a semaphore `rx.ready` to notify new received data buffer has
been added to H4 RX queue.

Wait for the semaphore `rx.ready` instead of H4 RX queue in HCI RX
thread.

Wake up the HCI RX thread when failing to allocate the RX buffer.

Fixes #89879.

Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jhedberg jhedberg

@lylezhu2012 lylezhu2012

@alwa-nordic alwa-nordic

Labels
area: Bluetooth HCI Bluetooth HCI Driver area: Bluetooth bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Drivers: Bluetooth: H4: Use a semaphore to wake up HCI RX thread nxp-upstream/zephyr
4 participants
@jhedberg @dkalowsk @lylezhu2012 @alwa-nordic