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/.
Max msuraev at sysmocom.deHi. 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 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 -- Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte