This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Osmocom BTS-side code (Abis, scheduling, ...)". The branch, neels/trx_double_init has been created at 8195b8d27da5700b003fadabcccb49dbe6ce9a83 (commit) - Log ----------------------------------------------------------------- http://cgit.osmocom.org/osmo-bts/commit/?id=8195b8d27da5700b003fadabcccb49d… commit 8195b8d27da5700b003fadabcccb49dbe6ce9a83 Author: Neels Hofmeyr &lt;neels(a)hofmeyr.de&gt; Date: Fri Jul 8 02:21:54 2016 +0200 osmo-bts-trx: init OML only once by sending AVSTATE_OK with OPSTATE_ENABLED When receiving an OPSTART for the BTS object, also set the availability state to OK. (Note, osmo-bts-trx so far has a hackish implementation of OML. It simply sends the ->Enabled state changes directly upon receiving an OPSTART.) Before, the availability would remain at NM_AVSTATE_DEPENDENCY, which caused an unfortunate chain reaction resulting in osmo-bts-trx going through the initialization sequence twice: BTS BSC |<-----| SITE_MANAGER OPSTART n |----->| BTS state change: OPSTATE_DISABLED, AVSTATE_DEPENDENCY o | | This signals to nm_statechg_event() in bts_ipaccess_nanobts.c r | | to (a) Set BTS Attributes and (b) send BTS OPSTART m |<-----| Set BTS Attributes (a) a | | When osmo-bts-trx receives a Set BTS Attributes, it sends l |----->| CHANNEL state change: OPSTATE_DISABLED x8 | | This signals the BSC to Set CHANNEL Attributes and OPSTART i |<-----| Set CHANNEL Attributes x8 n |<-----| CHANNEL OPSTART x8 i |----->| CHANNEL state change: OPSTATE_ENABLED, AVSTATE_OK x8 t | | |<-----| BTS OPSTART (b) | | osmo-bts-trx immediately replies with: |----->| BTS state change: OPSTATE_ENABLED, AVSTATE_DEPENDENCY | | Unfortunately, availability is left at DEPENDENCY, | | and the NM_OC_BTS case in nm_statechg_event() only | | checks for availability, not for the opstate. | | Hence nm_statechg_event() again feels inclined to | | to (a) Set BTS Attributes and (b) send BTS OPSTART, | | --+------+----- This is where the second round starts | | s |<-----| Set BTS Attributes (a) e | | When osmo-bts-trx receives a Set BTS Attributes, it sends c |----->| CHANNEL state change: OPSTATE_DISABLED x8 o | | All channels are disabled again, and then re-launched: n |<-----| Set CHANNEL Attributes x8 d |<-----| CHANNEL OPSTART x8 |----->| CHANNEL state change: OPSTATE_ENABLED, AVSTATE_OK x8 | | i |<-----| BTS OPSTART (b) n | | osmo-bts-trx again sets the OPSTATE_ENABLED, but since i | | this time it was already enabled, no further state change t | | is sent back to the BSC. This nightmare pivots on two hinges: 1. osmo-bts-trx fails to set BTS availability to AVSTATE_OK. 2. nm_statechg_event() fails to heed the OPSTATE_ENABLED of the BTS state change. Note, the configured channels from the first round were not actually taken down, only the OML OPSTATE_DISABLED were sent. In this commit, fix the osmo-bts-trx side: send AVSTATE_OK for the BTS object upon sending OPSTATE_ENABLED, so that only the part marked "normal init" above is run. This change applies the same fix to other OML objects, which should make sense in the same manner, within the current hackish OML implementation: * NM_OC_BTS * NM_OC_SITE_MANAGER * NM_OC_BASEB_TRANSC * NM_OC_GPRS_NSE * NM_OC_GPRS_CELL * NM_OC_GPRS_NSVC Change-Id: I08aa861f6100568c79750f4fbc9a32e1557b9304 ----------------------------------------------------------------------- hooks/post-receive -- Osmocom BTS-side code (Abis, scheduling, ...)