Yep, would certainly explain the high number of conn update failures I am seeing. However, it seems to just be a define in the code: https://github.com/apache/mynewt-core/blob/master/net/nimble/host/src/ble_gap.c#L86
I'll patch it for now, but i guess making this a syscfg setting is in order -- not being in syscfg is the reason i missed it originally. On Tue, Feb 6, 2018 at 11:57 AM, Christopher Collins <[email protected]> wrote: > On Mon, Feb 05, 2018 at 09:58:27PM -0800, Simon Ratner wrote: > > Thanks guys, I will try all of those and report back. > > > > First up, full mpool output. I just noticed ble_gap_update pool, which > > I don't remember seeing before. How come there is only one of those - > > is that per connection, or total concurrent updates? > > The `ble_gap_update` pool is shared by all connections. With 32 max > concurrent connections, you may want to increase the size of this pool a > bit (setting name: `BLE_GAP_MAX_UPDATE_ENTRIES`). However, I don't > think that is related to the leak you are seeing. > > > 1491016 Mempools: > > 1491016 name blksz cnt free min > > 1491018 msys_1 88 96 20 2 > > 1491019 ble_hci_ram_evt_hi_pool 72 32 31 22 > > 1491021 ble_hci_ram_evt_lo_pool 72 32 22 0 > > 1491023 ble_hs_hci_ev_pool 16 64 51 22 > > 1491024 ble_hs_conn_pool 100 32 29 24 > > 1491026 ble_l2cap_chan_pool 28 96 87 72 > > 1491027 ble_l2cap_sig_proc_pool 20 1 1 1 > > 1491029 ble_att_svr_prep_entry_pool 12 16 16 13 > > 1491031 ble_gap_update 24 1 1 0 > > 1491032 ble_gattc_proc_pool 56 32 1 0 > > 1491034 cmd_pool 64 64 58 53 > > 1491035 peer_pool 76 32 29 19 > > 1491037 peer_op_pool 28 64 63 53 > > 1491039 peer_addr_pool 32 48 47 40 > > 1491040 rcpt_pool 40 64 0 0 > > 1491042 ble_att_svr_entry_pool 20 29 0 0 > > 1491043 ble_gatts_clt_cfg_pool 8 33 29 24 > > Unfortunately, nothing jumps out at me (other than `msys_1` and > `ble_gattc_proc_pool` of course). > > Chris >
