summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorVadim Yanitskiy <vyanitskiy@sysmocom.de>2020-07-07 03:51:32 +0700
committerVadim Yanitskiy <vyanitskiy@sysmocom.de>2020-07-08 15:55:05 +0700
commitbb0609ed484977ff60faf3ac8256ce97f5f7c0a0 (patch)
tree74ee08eb95372718bc4ffe04a31aeee3fcb5ff3d
parenta29277278bffd6988d2715a1878dbb04a5243a1d (diff)
trxcon/scheduler: fix subst_frame_loss(): do not compensate too much
It's not something that we should be trying to fix, if the whole TDMA multi-frame is lost. For some yet unknown reason, sometimes the difference between the last processed TDMA frame number and the current one is so huge, so trxcon eats a lot of CPU trying to compensate nearly the whole TDMA hyper-frame: sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647) since the last processed fn=633 (current fn=632) Let's just print a warning and do not compensate more than one TDMA multi-frame period corresponding to the current layout. Change-Id: I56251d0d2f6fa19195ff105d3bdfbc22df6db8cd
-rw-r--r--src/host/trxcon/sched_trx.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/src/host/trxcon/sched_trx.c b/src/host/trxcon/sched_trx.c
index 79e6f88b..9195b336 100644
--- a/src/host/trxcon/sched_trx.c
+++ b/src/host/trxcon/sched_trx.c
@@ -640,6 +640,7 @@ static int subst_frame_loss(struct trx_lchan_state *lchan,
LOGP(DSCHD, LOGL_NOTICE, "Too many (>%u) contiguous TDMA frames elapsed (%u) "
"since the last processed fn=%u (current %u)\n",
mf->period, elapsed, lchan->tdma.last_proc, fn);
+ return -EIO;
} else if (elapsed == 0) {
LOGP(DSCHD, LOGL_ERROR, "No TDMA frames elapsed since the last processed "
"fn=%u, must be a bug?\n", lchan->tdma.last_proc);