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/.
pespin gerrit-no-reply at lists.osmocom.orgpespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-pcu/+/25769 ) Change subject: tbf_fsm: Handle MAX_N3105 in state ASSIGN ...................................................................... tbf_fsm: Handle MAX_N3105 in state ASSIGN Seen on a runnig osmo-pcu against real MS: """ pdch_ul_controller.c:329 PDCH(bts=0,trx=1,ts=7) Timeout for registered POLL (FN=751140): TBF(TFI=0 TLLI=0xe8c12143 DIR=UL STATE=ASSIGN EGPRS) tbf.cpp:542 TBF(TFI=0 TLLI=0xe8c12143 DIR=UL STATE=ASSIGN EGPRS) poll timeout for FN=751140, TS=7 (curr FN 751140) tbf.cpp:384 TBF(TFI=0 TLLI=0xe8c12143 DIR=UL STATE=ASSIGN EGPRS) N3105 exceeded MAX (8) tbf.cpp:594 TBF(UL-TFI_0)[9bc050]{ASSIGN}: Received Event MAX_N3105 tbf.cpp:594 TBF(UL-TFI_0)[9bc050]{ASSIGN}: Event MAX_N3105 not permitted """ It was first though when FSMs where introduced that an FSM in ASSIGN state could not receive this kind of event because it was believed to be sending no CTRL blocks at all until flow state. That's because the believe was that Assignment over PACCH was done by another existing TBF. It turns out this is usually the case, but not in all cases. In at least one case, the tbf object (and tbf_fsm/tbf_{ul,dl}_ass_fsm) itself is handling its own assignment (hence eg. sending the UL assignment and waiting response through tbf_ul_ass_fsm. This happens if a UL TBF sends a Pkt Resource Req as a response to RRBP of final UL ACK/NACK in order to request a new TBF, where it temporarily uses the control_ts of the previous TBF to get a new Pkt UL Assignment over PACCH. If Pkt Ul Assignment doesn't receive a CTRL ACK, tbf_ul_ass_fsm will retrnamist it, until MAX_N3015 is reached (the event we failed to handle until now). At this point, we really want to transition to RELEASING in order to avoid keeping the TBF allocating resources (until X2001 times out). Related: SYS#5647 Change-Id: I86d5c1bbccd06673d08451b812d149e727404733 --- M src/tbf_fsm.c 1 file changed, 6 insertions(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/osmo-pcu refs/changes/69/25769/1 diff --git a/src/tbf_fsm.c b/src/tbf_fsm.c index d1d4668..84d5bcc 100644 --- a/src/tbf_fsm.c +++ b/src/tbf_fsm.c @@ -188,6 +188,10 @@ /* change state to FLOW, so scheduler will start transmission */ tbf_fsm_state_chg(fi, TBF_ST_FLOW); break; + case TBF_EV_MAX_N3105: + ctx->T_release = 3195; + tbf_fsm_state_chg(fi, TBF_ST_RELEASING); + break; default: OSMO_ASSERT(0); } @@ -409,7 +413,8 @@ X(TBF_EV_ASSIGN_ADD_PACCH) | X(TBF_EV_ASSIGN_ACK_PACCH) | X(TBF_EV_ASSIGN_PCUIF_CNF) | - X(TBF_EV_ASSIGN_READY_CCCH), + X(TBF_EV_ASSIGN_READY_CCCH) | + X(TBF_EV_MAX_N3105), .out_state_mask = X(TBF_ST_FLOW) | X(TBF_ST_FINISHED) | -- To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/25769 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Change-Id: I86d5c1bbccd06673d08451b812d149e727404733 Gerrit-Change-Number: 25769 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: dexter <pmaier at sysmocom.de> Gerrit-MessageType: newchange -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20211013/ba55d4e2/attachment.htm>