#95 Empty out of nr_acl_pkts semaphore
I observed an empty out of nr_acl_pkts semaphore as showed below. This issue stops the whole ACL communication and can also provoke the Connection Event Buffer overflow (by acquiring nr_acl_pkts within the callbacks).
The nr_acl_pkts semaphore was set to 8 on init, only CM and TM is running, after some time the following lines are printed:
[jaws@01:9c]$ 510 1545937 C05, INF: inq done: 7 devices found.
511 1550955 C05, INF: error con create: (0x0004)!
512 1550956 C05, INF: nr_acl_pkts: 0
513 1550957 C05, INF: inq sleep 16622
514 1570541 C05, INF: inq done: 7 devices found.
515 1576906 C05, INF: error con create: (0x0010)!
516 1576907 C05, INF: nr_acl_pkts: 0
517 1576908 C05, INF: inq sleep 13039
518 1593077 C05, INF: inq done: 6 devices found.
519 1598256 C05, INF: DISCONNECTION (handle 119)
520 1599205 C05, INF: error con create: (0x0010)!
521 1599206 C05, INF: nr_acl_pkts: 0
522 1599207 C05, INF: inq sleep 4749
523 1607471 C05, INF: inq done: 6 devices found.
524 1612845 C05, INF: error con create: (0x0010)!
Discussion
Logged In: YES
user_id=749518
Possible causes:
Note: the nr_acl_semaphore are posted/released though BT_HCI_NUMBER_OF_COMPLETED_PACKETS events
- loss of BT_HCI_NUMBER_OF_COMPLETED_PACKETS events
- the BT specs writes about a special disconnection behaviour:
"When the Host receives a Disconnection Complete event, the Host shall
assume that all unacknowledged HCI Data Packets that have been sent to the
Controller for the returned Connection Handle have been flushed, and that the
corresponding data buffers have been freed. The Controller does not have to
notify the Host about this in a Number Of Completed Packets event."
Logged In: YES
user_id=749518
I wrote a small code to display the current values of all
bt_semaphores (using bt_semaphore_register_cmds()). Here are
the results.
Initial values:
[jaws@01:c0]$sema
sema 0x4ee7: 8 (nr_acl_pkts)
sema 0x4efc: 24 (nr_sco_pkts)
sema 0x4ee3: 1 (acl_link.sema)
sema 0x4f06: 1 (inquiry)
sema 0x4cbc: 1 (sem_write)
sema 0x4cc1: 1 (nr_hci_cmds)
sema 0x4cc5: 1 (hci_cmd_queue)
sema 0x4f2b: 1 (single_cmd)
sema 0x6670: 1 (rel_con_mutex)
After a certain time:
[jaws@01:c0]$sema
sema 0x4ee7: 0 (nr_acl_pkts)
sema 0x4efc: 24
sema 0x4ee3: 0 (acl_link.sema)
sema 0x4f06: 1
sema 0x4cbc: 1
sema 0x4cc1: 1
sema 0x4cc5: 1
sema 0x4f2b: 11 (single_cmd)
sema 0x6670: 1
Comment: Unresponsible (to dsn ping) nodes has nr_acl_pkts
and acl_link.sema semaphores with value 0. All nodes has
some increasing single_cmd values (also bad).
Logged In: YES
user_id=687107
Originator: NO
could this be fixed by the "ACL packet send trashes CMD packets" bug I've found yesterday?
the > 1 single_cmd sema might be cause by something else
Logged In: YES
user_id=687107
Originator: NO
hey musti,
can you reproduce this problem with the fixed bt stack.
if not, please close this item.
you can open a new one, if it should happen again.