From bb0609ed484977ff60faf3ac8256ce97f5f7c0a0 Mon Sep 17 00:00:00 2001 From: Vadim Yanitskiy Date: Tue, 7 Jul 2020 03:51:32 +0700 Subject: [PATCH] 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 --- src/host/trxcon/sched_trx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/host/trxcon/sched_trx.c b/src/host/trxcon/sched_trx.c index 79e6f88b1..9195b3369 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);