osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master
tom at tsou.cc
Tue Apr 12 00:04:13 UTC 2016
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
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
> * 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.
More information about the OpenBSC