Change in osmocom-bb[master]: firmware/layer1: fix properly apply secondary multi-frame task

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/.

laforge gerrit-no-reply at lists.osmocom.org
Fri Jul 31 16:09:26 UTC 2020


laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmocom-bb/+/19480 )

Change subject: firmware/layer1: fix properly apply secondary multi-frame task
......................................................................

firmware/layer1: fix properly apply secondary multi-frame task

When a dedicated channel is activated, in chan_nr2mf_task_mask()
we calculate a bitmask of the corresponding multi-frame tasks to
be enabled.  Three logical kinds of the multi-frame tasks exist:

  - primary (master) - the main burst processing task,
    e.g. MF_TASK_{TCH_F_ODD,SDCCH4_0,GPRS_PDTCH};
  - secondary - additional burst processing task (optional),
    e.g. MF_TASK_GPRS_PTCCH;
  - measurement - neighbour measurement task (optional),
    e.g. MF_TASK_NEIGH_{PM51,PM26E,PM26O}.

By default, the primary task is set to MF_TASK_BCCH_NORM (0x00).
Due to a mistake, the secondary task has also been set to BCCH,
so when we switch to a dedicated mode, we also enable the BCCH.

This leads to a race condition between the multi-frame tasks,
when both primary and secondary ones read bursts from the DSP
at the same time, so the firmware hangs because of that:

  nb_cmd(0) and rxnb.msg != NULL
  BURST ID 2!=0 BURST ID 3!=1

This regression was introduced together with experimental PDCH
support [1].  Let's use value -1 to indicate that the secondary
task is not set, and apply it properly.

Change-Id: I4d667b2106fd8453eac9e24019bdfb14358d75e3
Fixes: [1] I44531bbe8743c188cc5d4a6ca2a63000e41d6189
Related: OS#3155
---
M src/target/firmware/layer1/l23_api.c
1 file changed, 5 insertions(+), 3 deletions(-)

Approvals:
  Jenkins Builder: Verified
  laforge: Looks good to me, approved



diff --git a/src/target/firmware/layer1/l23_api.c b/src/target/firmware/layer1/l23_api.c
index e9ce032..4621bfc 100644
--- a/src/target/firmware/layer1/l23_api.c
+++ b/src/target/firmware/layer1/l23_api.c
@@ -77,8 +77,8 @@
 	uint8_t cbits = chan_nr >> 3;
 	uint8_t tn = chan_nr & 0x7;
 	uint8_t lch_idx;
-	enum mframe_task master_task = 0;
-	enum mframe_task second_task = 0;
+	enum mframe_task master_task = MF_TASK_BCCH_NORM;
+	enum mframe_task second_task = -1; /* optional */
 	enum mf_type multiframe = 0;
 	uint32_t task_mask = 0x00;
 
@@ -123,7 +123,9 @@
 	}
 
 	/* Primary and secondary tasks */
-	task_mask |= (1 << master_task) | (1 << second_task);
+	task_mask |= (1 << master_task);
+	if (second_task >= 0) /* optional */
+		task_mask |= (1 << second_task);
 
 	switch (neigh_mode) {
 	case NEIGH_MODE_PM:

-- 
To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/19480
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmocom-bb
Gerrit-Branch: master
Gerrit-Change-Id: I4d667b2106fd8453eac9e24019bdfb14358d75e3
Gerrit-Change-Number: 19480
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-MessageType: merged
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200731/a0d838f5/attachment.htm>


More information about the gerrit-log mailing list