This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Tom Tsou tom at tsou.ccHarald, Thank you for the thorough log analysis which is greatly helpful. On Sat, Apr 9, 2016 at 3:25 AM, Harald Welte <laforge at 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