Hi, the branch is not done yet but I am confident about the first couple of commits and would like to have some extra eyes to take a look. The branch is here[1] and the general goal is to improve the reliability of the code. Under heavy use it is possible that the nitb will mark all lchans as broken. While doing the tests I noticed the following issues: 1.) On Call-Control with fast hangups (during channel modify) I can see empty FACCH messages from the DSP gsm queue. 2.) The wlc/prim request handling has the known and documented limitation that for a given confirm we do not know who sent the request. This can lead to call the 'wrong' callback with the wrong data/closure. I addressed this the following way: 1.) Add a u8Size == 0 check. For the SACCH we added a < 2 check. Should we check if a LAPDm header could fit? What would be the best limit? I have only seen u8Size == 0, so this is what I addressed.[2] 2.) I address it by passing the gsm_bts_trx as the data pointer and saving the lchan identifier in the hLayer3 pointer and then resolve the lchan from the TS. In follow up commits I introduced a new function to enter the Gsm primitive into the queue and I plan to change the callback signature for them to always include the TRX anyway. The main change is here[3]. There is still a clash between the Ciphering and the TxPower... 3.) The next commits should fix the reliability issue. I do this by keeping a queue of outstanding SAPI operations. And ACK ABIS requests when the queue becomes empty. This is mostly working right now but I have one issue with the ChannelReleaseMarker. When sending a SACCH DEACTIVATE and before the two SACCHs are deactivated send a RF Channel Release the queue appears to be stuck. cheers holger [1] http://cgit.osmocom.org/cgit/osmo-bts/log/?h=zecke/channel-release [2] http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=zecke/channel-release&i… [3] http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=zecke/channel-release&i…