Bug #4804
closedTCH/F: Prim has wrong chan_nr=0xc5 link_id=00, expecting chan_nr=0x0d link_id=00
100%
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.
Updated by fixeria over 3 years 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()
Updated by laforge over 3 years ago
- Status changed from Feedback to Resolved
resolved, patches merged.