Hi.
I'd like to get back to the status of this one. Are there any patches available somewhere which I could try? Do we have a ticket to track this or shall I make one?
On 04/12/2016 02:04 AM, Tom Tsou wrote:
Harald,
Thank you for the thorough log analysis which is greatly helpful.
On Sat, Apr 9, 2016 at 3:25 AM, Harald Welte laforge@gnumonks.org wrote:
Looking at the got log, the above function call of oml_mo_tx_sw_act_rep() for the baseband transceiver was always sent unconditionally from within check_tranceiver_availability() even in Jolly's original osmo-bts-trx code from February 2013, see commit acc71ffb4b61b3354bbb2fa14981e4e6a46946e6. THe code even states that iti s a HACK and it should only be done once we receive CLOCK indications from osmo-trx. However, even that is wrong, as CLOCK is already received in Frame 11, too soon to make that a criterion.
I noticed the behavior surrounding check_transceiver_availability() seemed suspect, but I wasn't sure about related effects. Indeed, if I restrict sections of check_transceiver_availability() containing oml_mo_tx_sw_act_rep() to running once, I am able to reach a functional OML setup (sometimes to the point of TCH channel establishment).
Related is the question of when osmo-trx should send CLOCK indications. Right now a CLOCK indications is sent with arrival of commands on the control interface. After starting, CLOCK indications are sent at an one second interval (216 frames). The indications sent from the control interface are why osmo-bts is receiving CLOCK so early.
Solution:
- OML initialization (the most complex part of Abis) needs to be more properly handled. No part of the code should do something like dynamically sending software activation reports at runtime. In osm-bts-trx, every time 'transceiver_available' goes from 0->1 (which apparently can happen even after start), a software activation report is sent to the BSC. This is wrong. The software is only activated once during boot, and it is activated not before the parent MOs for BTS and Site Manager are enabled.
I can confirm that the sending of SW activation reports is currently broken and prevents usable operation with osmo-bts-trx. To start, I'll look into a better approach to the 'transceiver_available' state and limiting SW activation messages. Hopefully that can at least get us to a usable state with osmo-bts-trx.
Unrelated to that, osmo-bts-trx desparately needs to avoid the use of global variables. Each gsm_bts_trx / gsm_bts / phy_link / phy_instance has private data store for implementation-specific state. global variables have always been discouraged.
Agreed and noted.
-TT