bsc: Fix lchan iteration for dyn TS during PDCH Deact

In general PDCH channels are not handled as lchans in BSC (lchan_fsm.c),
and so when a TS is in ts->pchan_is=GSM_PCHAN_PDCH, no lchan slot is
being used.

However, during Dynamic TS PDCH Deactivation being in progress (state
WAIT_PDCH_DEACT in timeslot_fsm.c), ts->pchan_is =GSM_PCHAN_PDCH, but
an lchan slot of that TS is actually already being used by a TCH lchan:
it's the one who initiated the deactivate in order to be able to use the TS.

While being in WAIT_PDCH_DEACT state and receiving a PDCH DEACT NACK,
ts_fsm_error() was called in order to kill the TS and it was expected
that it would kill any lchan using it (or willing to start using it). In
order to do that, it calls ts_lchans_dispatch() which in turns iterates
over all lchans attached to the TS using ts_for_each_lchan().

However, when the NACK arrived we still had ts->pchan_is=GSM_PCHAN_PDCH,
ts_for_each_lchan ends up calling
ts_as_pchan_for_each_lchan(GSM_PCHAN_PDCH), which in turns calls
pchan_subslots(GSM_PCHAN_PDCH) which returns 0, because we don't manage
lchans in that mode as explained in first paragraph. This means in this
case ts_for_each_lchan() is actually an empty loop while still any of
the TCH channels may be in use, and won't be advertised about the TS
entering in a broken state.

As a result, the lchan won't be released for a while, only after T23001
expires.

Related: OS#3708
Change-Id: I9cedb77d6578597f1febab36c54b2ee427c7a4a2
This commit is contained in:
Pau Espin 2018-11-28 16:47:10 +01:00
parent 0ba20df9ee
commit 746dbc9fdd
1 changed files with 1 additions and 1 deletions

View File

@ -123,7 +123,7 @@ static void ts_lchans_dispatch(struct gsm_bts_trx_ts *ts, int lchan_state, uint3
{
struct gsm_lchan *lchan;
ts_for_each_lchan(lchan, ts) {
ts_for_each_potential_lchan(lchan, ts) {
if (lchan_state >= 0
&& !lchan_state_is(lchan, lchan_state))
continue;