doc: Add known issue for TX processor block

Adds a known issue for the TX processor being blocked if a callback is
blocking when run in the system workqueue, and the HCI command buffer
pool is empty.

Signed-off-by: Håvard Reierstad <[email protected]>

doc/nrf/releases_and_maturity/known_issues.rst

@@ -189,6 +189,17 @@ KRKNWK-14299: NRPA MAC address cannot be set in Zephyr
 Bluetooth LE
 ============
 
+.. rst-class:: v2-9-0-nRF54H20-1 v2-9-0 v2-8-0
+
+NCSDK-31528: Deadlock on sysworkq with ``tx_notify`` in Host
+  If a blocking callback is run on the system workqueue when the HCI buffer pool is full, the TX processor will be blocked.
+  This prevents TX buffers from being freed, deadlocking the application.
+  An example of a blocking callback is calling the :c:func:`bt_conn_get_tx_power_level` function in a receive callback, which is blocking since it uses the :c:func:`bt_hci_cmd_send_sync` function.
+
+  **Workaround:** Do not use blocking calls in the system workqueue.
+  Alternatively, increase the value of the :kconfig:option:`CONFIG_BT_BUF_CMD_TX_COUNT` Kconfig option to increase the HCI buffer.
+  This does not guarantee that the problem is solved, as multiple blocking calls may exhaust the buffer pool.
+
 .. rst-class:: v2-9-0-nRF54H20-rc1 v2-9-0 v2-8-0 v2-7-0 v2-6-2 v2-6-1 v2-6-0
 
 NCSDK-31095: Issues with the :kconfig:option:`CONFIG_SEGGER_SYSVIEW` Kconfig option