This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
Neels Hofmeyr gerrit-no-reply at lists.osmocom.orgPatch Set 2: (1 comment) https://gerrit.osmocom.org/#/c/713/2/openbsc/src/libbsc/abis_rsl.c File openbsc/src/libbsc/abis_rsl.c: Line 1134: dyn_ts_switchover_complete(lchan); so this first "accepts" the act ack, but then tells the BTS to release the channel right away. For dyn TS it might be safer to set dyn.pchan_is = dyn.pchan_want = GSM_PCHAN_NONE, because of the logic in rsl_rx_rf_chan_rel_ack(): switching on PDCH will only happen if pchan_is != GSM_PCHAN_PDCH and if pchan_is == pchan_want. If the broken state happened while trying to switch to PDCH, lchan->type might be set to none, the call to dyn_ts_switchover_complete() will thus set pchan_is = PDCH and rsl_rx_rf_chan_rel_ack() will skip the PDCH activation. But after the broken state we might need that to happen? To clarify: "release" normally means "release voice", and for dyn TS that is synonymous to "activate data", so we always want to activate PDCH after this. Complication: dyn TS also introduce a non-std chan act and rf_chan_release message for PDCH, so we could also receive an act ack here that was meant for the PDCH activation request. I'm only trying to figure this out theoretically. Do you have a scenario to test this and make sure? Can a broken channel happen anytime, or only in specific cases? -- To view, visit https://gerrit.osmocom.org/713 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I63dc0deaf15ba7c21e20b1e0c7b85f0437e183ed Gerrit-PatchSet: 2 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Holger Freyther <holger at freyther.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de> Gerrit-HasComments: Yes