Skip to content

Changes

Started by upstream project gerrit-osmo-bts #1129
Started 1 day 21 hr ago
Queued 5.3 sec
Took 4 min 49 sec on build5-deb12build-ansible
bts_shutdown_fsm: fix spurious RAMP_COMPL events in WAIT_TRX_CLOSED

With multiple TRXes ramping down in lockstep, both their final
ramp-timer callbacks fire back-to-back in the same event loop pass,
setting p_total_cur_mdBm to the target value for both before any async
hardware acknowledgement arrives.  When the first SETPOWER ack returns
and fires ramp_down_compl_cb() for TRX0, the remaining-TRX check in
st_wait_ramp_down_compl() inspects p_total_cur_mdBm for TRX1 and finds
it already at the target - concluding that all TRXes are done.  The FSM
then transitions to WAIT_TRX_CLOSED, and the second ack (for TRX1)
fires ramp_down_compl_cb() into the wrong state, producing:

  BTS_SHUTDOWN(...){WAIT_TRX_CLOSED}: Event BTS_SHUTDOWN_EV_TRX_RAMP_COMPL not permitted

The root cause is that p_total_cur_mdBm is a *requested* value set in
the timer callback, not a confirmed one.  The hardware confirmation
arrives asynchronously via power_trx_change_compl() ->
power_ramp_do_step(), which is also where compl_cb() is invoked.

Fix by adding a 'complete' flag to trx_power_params.ramp that is:

* cleared when _power_ramp_start() begins a new ramp, and
* set just before compl_cb() is called in power_ramp_do_step()

The shutdown FSM remaining-TRX count then checks !ramp.complete instead of
comparing p_total_cur_mdBm against the target, correctly reflecting which
TRXes have actually received hardware confirmation of ramp completion.

Change-Id: Ia71393e871187d6b44b7f520eb421bab354aafd1
Vadim Yanitskiy at