Actions
Bug #4695
closedRF-locking makes osmo-bts-trx lose all per-timeslot rate counters
Start date:
08/06/2020
Due date:
% Done:
100%
Spec Reference:
Description
I found this just by looking at the related code:
/* Deact RF on transceiver */
int bts_model_trx_deact_rf(struct gsm_bts_trx *trx)
{
// ...
/* close all logical channels and reset timeslots */
trx_sched_reset(&l1h->l1s);
// ...
}
In this case, resetting the scheduler is kind of expected, but let's look at the actual implementation:
/* close all logical channels and reset timeslots */
void trx_sched_reset(struct l1sched_trx *l1t)
{
trx_sched_exit(l1t); // <-- (!)
trx_sched_init(l1t, l1t->trx);
}
and here is the culprit, in trx_sched_exit():
void trx_sched_exit(struct l1sched_trx *l1t)
{
struct gsm_bts_trx_ts *ts;
uint8_t tn;
int i;
LOGP(DL1C, LOGL_NOTICE, "Exit scheduler for trx=%u\n", l1t->trx->nr);
for (tn = 0; tn < ARRAY_SIZE(l1t->ts); tn++) {
struct l1sched_ts *l1ts = l1sched_trx_get_ts(l1t, tn);
msgb_queue_flush(&l1ts->dl_prims);
rate_ctr_group_free(l1ts->ctrs); // <-- (!)
l1ts->ctrs = NULL; // <-- (!)
// ...
}
// ...
}
Related issues
Updated by laforge over 3 years ago
On Wed, Aug 05, 2020 at 10:18:31PM +0000, fixeria [REDMINE] wrote:
In this case, resetting the scheduler is kind of expected, but let's look at the actual implementation:
one more reason to never reset or stop the scheduler, as pointed out in my comment to #4694
Updated by fixeria over 3 years ago
- Related to Bug #4696: osmo-bts-trx keeps sending dummy bursts after being RF-locked added
Updated by pespin over 3 years ago
- Status changed from New to Feedback
- Assignee set to fixeria
This should be fixed after the inclusion of the TRXC RFMUTE feature, since we don't reset the scheduler anymore. Please give a try and mark as resolved if that's the case.
Updated by fixeria over 3 years ago
- Status changed from Feedback to Resolved
- % Done changed from 0 to 100
Not a problem anymore, thanks!
Actions