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 updated discards c890c8abe7b93693ac6d20cc0c1076b4549ae3ba (commit) via 2ed03cd640fa13adb1d408f300b4a326c2ecbdff (commit) This update added new revisions after undoing existing revisions. That is to say, the old revision is not a strict subset of the new revision. This situation occurs when you --force push a change and generate a repository containing something like this: * -- * -- B -- O -- O -- O (c890c8abe7b93693ac6d20cc0c1076b4549ae3ba) \ N -- N -- N (2ed03cd640fa13adb1d408f300b4a326c2ecbdff) When this happens we assume that you've already had alert emails for all of the O revisions, and so we here report only the revisions in the N branch from the common base, B. Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://cgit.osmocom.org/osmo-bts/commit/?id=2ed03cd640fa13adb1d408f300b4a326... commit 2ed03cd640fa13adb1d408f300b4a326c2ecbdff Author: Neels Hofmeyr <neels@hofmeyr.de> 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. 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 This means that the NM_OC_CHANNEL case just above is identical, and thus collapse NM_OC_CHANNEL onto the other cases. Drop the comments from NM_OC_CHANNEL since they merely rephrase the commands themselves. See OS#1770 for BTS and NITB logs. Fixes: OS#1770 Change-Id: I08aa861f6100568c79750f4fbc9a32e1557b9304 ----------------------------------------------------------------------- Summary of changes: src/osmo-bts-trx/l1_if.c | 10 ---------- 1 file changed, 10 deletions(-) hooks/post-receive -- Osmocom BTS-side code (Abis, scheduling, ...)