dyn TS: fix TCH/F_TCH/H_PDCH: properly record release of PDCH TS

When a release of PDCH is complete, actually set the dyn.pchan_is to NONE.

Failure to do so currently caused errors on activation of an Osmocom style dyn
TS as TCH, in the shape of:

	rsl.c:636 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK
	rsl.c:164 (bts=0,trx=0,ts=2,pchan=TCH/F_TCH/H_PDCH switching PDCH -> NONE) RSL rx DCHAN: mismatching chan_nr=0x12
	rsl.c:2611 Rx RSL CHAN_ACTIV for unknown lchan
	rsl.c:710 0x12: Sending Channel Activated NACK: cause = 0x64

The Tx RF CHAN REL ACK shows that we're through with PDCH release, but the
following line showing "chan=TCH/F_TCH/H_PDCH switching PDCH -> NONE" shows
that the state still reflects active switching.  Thus the DCHAN code decides
that the chan_nr = 0x12 reflecting a TCH/H on TS 2 is a mismatch and NACKs the
TCH activation.

(For ip.access style TCH/F_PDCH, the ts->flags are cleared in
ipacc_dyn_pdch_complete()).

Related: OS#3235
Change-Id: Ic06c8f0fe82ae8a06afa5defd93a685010687965
This commit is contained in:
Neels Hofmeyr 2018-05-04 22:20:44 +02:00
parent ca262ffa73
commit ac5e2bc329
1 changed files with 2 additions and 0 deletions

View File

@ -634,6 +634,8 @@ int rsl_tx_rf_rel_ack(struct gsm_lchan *lchan)
gsm_ts_and_pchan_name(lchan->ts), lchan->nr);
/* well, what to do about it ... carry on and hope it's fine. */
}
/* remember the fact that the TS is now released */
lchan->ts->dyn.pchan_is = GSM_PCHAN_NONE;
/* Continue to ack the release below. (This is a non-standard rel ack invented
* specifically for GSM_PCHAN_TCH_F_TCH_H_PDCH). */
send_rel_ack = true;