Project

General

Profile

Bug #4804

TCH/F: Prim has wrong chan_nr=0xc5 link_id=00, expecting chan_nr=0x0d link_id=00

Added by fixeria 8 days ago. Updated 2 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
dynamic PDCH
Target version:
-
Start date:
10/13/2020
Due date:
% Done:

100%

Spec Reference:

Description

This message appears when a dynamic timeslot is switched from PDCH to TCH/F. I assume that somehow the transmit queue of the timeslot is not properly cleaned. So after switching to TCH/F (expected chan_nr=0x0d), the scheduler takes a PDCH frame (21 octets, chan_nr=0xc5) from Tx queue, and discards it. It's not really critical, but may confuse the user. We need to flush the queues.

History

#1 Updated by fixeria 4 days ago

  • Status changed from New to In Progress

#2 Updated by fixeria 4 days ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100

I've submitted a patch cleaning the Tx queue on lchan deactivation:

https://gerrit.osmocom.org/c/osmo-bts/+/20700 scheduler: remove pending Tx prims on lchan deactivation

together with a bunch of small changes:

https://gerrit.osmocom.org/c/osmo-bts/+/20693 scheduler: ensure PRIM_OP_REQUEST when adding to the queue
https://gerrit.osmocom.org/c/osmo-bts/+/20694 scheduler: _sched_dequeue_prim(): make 'l1sap' a scoped pointer
https://gerrit.osmocom.org/c/osmo-bts/+/20695 scheduler: use RSL_CHAN_NR_MASK in trx_sched_set_lchan()
https://gerrit.osmocom.org/c/osmo-bts/+/20696 scheduler: drop meaningless check in trx_sched_set_lchan()
https://gerrit.osmocom.org/c/osmo-bts/+/20697 scheduler: reduce nesting in trx_sched_set_lchan()
https://gerrit.osmocom.org/c/osmo-bts/+/20698 scheduler: treat subsequent lchan (de)activation as error
https://gerrit.osmocom.org/c/osmo-bts/+/20699 scheduler: join conditions in trx_sched_set_lchan()

#3 Updated by laforge 2 days ago

  • Status changed from Feedback to Resolved

resolved, patches merged.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)