Bug #3173
closedBTS_Tests.TC_sacch_multi_chg fails
0%
Description
The test BTS_Tests.TC_sacch_multi_chg fails. This is most likely due to the fact that we copy all SI buffers from the per-TRX global buffers to the per-lchan during activation of the lchan, but then don't update the per-lchan copies of active lchan's when a new SACCH FILL is receive for the entire BTS/TRX
Updated by stsp over 5 years ago
- Status changed from New to In Progress
I'm investigating this. Currently stuck at trying to get the BTS tests to run normally.
Many SAACH related tests are failing with errors like:
MC@fintan: Test Component 55 has requested to stop MTC. Terminating current testcase execution.
MTC@fintan: Test case TC_sacch_filling finished. Verdict: fail reason: Received unknown primitive from IPA MTC@fintan: Test case TC_sacch_info_mod started.
close_fd10
MC@fintan: Test Component 59 has requested to stop MTC. Terminating current testcase execution.
MTC@fintan: Test case TC_sacch_info_mod finished. Verdict: fail reason: Received unknown primitive from IPA MTC@fintan: Test case TC_sacch_multi started.
close_fd11 MC@fintan: Test Component 63 has requested to stop MTC. Terminating current testcase execution.
MTC@fintan: Test case TC_sacch_multi finished. Verdict: fail reason: Received unknown primitive from IPA MTC@fintan: Test case TC_sacch_multi_chg started.
close_fd12 MC@fintan: Test Component 67 has requested to stop MTC. Terminating current testcase execution.
MTC@fintan: Test case TC_sacch_multi_chg finished. Verdict: fail reason: Received unknown primitive from IPA
I am not sure yet what is going on. I suspect a local problem in my setup.
Updated by stsp over 5 years ago
Proposed patch: https://gerrit.osmocom.org/c/osmo-bts/+/10153
This patch updates all lchans which aren't in state NONE. Is this OK or should we be more selective about which lchans get updated?
Updated by laforge over 5 years ago
Hi!
On Tue, Jul 24, 2018 at 06:05:07PM +0000, stsp [REDMINE] wrote:
This patch updates all lchans which aren't in state NONE. Is this OK or should we be more selective about which lchans get updated?
I'm not sure the semantics are 100% correct. Let's assume the following scenario:
a) the BTS/TRX global SI filling for SI5 is set to A
b) most channels use A, but on one channel (Y) the BSC sets per-channel SI5 to B
c) the BTS/TRX global SI filling for SI5 is set to C
- channel Y transmits B, because B had overridden A
- only all channels without per-channel specific SACCH filling override are updated to C
The proposed implemenation will "forget" that channel Y had an override in place.
Updated by stsp over 5 years ago
Right, that makes sense. See https://gerrit.osmocom.org/#/c/osmo-bts/+/10156 -- good enough?
Updated by stsp over 5 years ago
stsp wrote:
Right, that makes sense. See https://gerrit.osmocom.org/#/c/osmo-bts/+/10156 -- good enough?
One problem with this proposed patch:
a) Given initial BTS-global SI value A
b) On lchan X, set override to value B with SACCH INFO MOD
c) Switch global SI value to B with SACCH FILLING
d) Switch global SI value back to A with SACCH_FILLING: Now lchan X switches back to value A as well.
To keep lchan X's override, we'd need something like a set of flags on each lchan which indicates whether or not a specific SI value was set to a non-global SI value by a SACCH INFO MOD command.
Updated by stsp over 5 years ago
Uploaded a new patch set (number 2, same URL) which addresses the above problem.
Updated by stsp over 5 years ago
- Status changed from In Progress to Resolved
Above changes have been merge and the test is now passing. Closing this issue.
